Independent Task: Prerequisite Review

Before getting started with the main portion of the guided project, please complete the prerequisite review.

You will be graded on completion of the task; you will not be penalized for incorrect answers.

The problems will include code tracing so you’ll want to have scrap paper available as you work through the problems. You can also reference a resource on pseudocode. These problems should be completed independently and with out assistance from other students or the teaching staff (remember, you’re not being graded on correctness - just completion).

If you have not already indicated your consent status for the SRCSL research study, as posted on Moodle, you will be asked to indicate your consent status before the prerequisite review. Your decision to consent to the SRCSL study, or not, will not impact your ability to complete the prerequisite review. If you have any questions about the SRCSL study please email Tommy Bacher (jtbacher@ncsu.edu).

Complete the prerequisite review!.

Guided Task: Guided Project 2 GitHub Repository

You will be assigned a separate GitHub repository for each Guided Project and each major Project. This is to ensure that your work on each is distinct and that any work on a new project doesn’t get recorded as late work on an old project. However, you will continue with the same WolfScheduler project for GP2. You need to share the project to your GP2 repository.

Learning Outcomes

• Disconnect a project from a GitHub repository
• Share a project with a new GitHub repository
• Push changes to a new remote GitHub repository

Best Practice: Version Control

A project may belong to only a single local repository. That is because a Git repository is represented as a folder on a file system with a special .git/ folder that stores Git metadata. The same project cannot be in two locations on the file system at once. The process outlined below will let you share an existing Eclipse project with a new repository and then retain a copy of your Guided Project 1 submission in a local copy of your Guided Project 1 repository.

Tools: Git and GitHub

Git is a distributed version control system. Git supports the creation of repositories, copying of repositories (cloning), committing changes, working with remote repositories, and merging changes. In Git, all repositories are considered equal and each maintains its own history. You can move information between connected repositories through pulling and pushing any changes.

Disconnect WolfScheduler from GP1 Repository

Disconnecting a project from a Git repository removes any associated metadata about the project from the repository. To disconnect, do the following:

• Right click on the WolfScheduler project
• Select Team > Disconnect.
• The repository name to the right of the WolfScheduler project will no longer be available.

Push WolfScheduler to your GP2 Repository

Complete the following steps to push WolfScheduler to your GP2 repository.

• Clone your GP2 repository provided by the teaching staff. The pattern will be csc216-GP2-XXX-YYY, where XXX is your section number and YYY is your repository number.
• Stage your WolfScheduler to your GP2 repository by right clicking on the project and selecting Team > Share Project.
• In the Configure Git Repository pop-up, uncheck the option Use or create repository in parent folder of project. Then select your new repository from the drop down and check your project.

• Now that your project is staged for the GP2 repository, add the files to the index by right clicking on the WolfScheduler project and selecting Team > Add to index. Then Commit and Push the project to start GP2! Use a commit message like “[Skeleton] Starting GP2 with GP1 WolfScheduler”.
• You may need to refresh the Git Staging view for the files to show as staged. It’s also ok if you don’t have some of the .gitignore files that are in the screenshot.

Reset your GP1 WolfScheduler

When you shared the WolfScheduler project with your new GP2 repo, that removed the WolfScheduler directory from your local GP1 repo directory. If you want to keep a copy of your GP1 WolfScheduler, you should reset your local GP1 repository to the last commit in the remote. Then your local GP1 repository will have a copy of your final GP1 WolfScheduler submission. You can use that as a backup as you’re working on GP2!

Choose to do the reset in either Eclipse or Git Bash!

In Eclipse, do the following:

• Right click on your GP1 repository in the Git Repositories view and select Reset.
• Make sure the last commit is selected and select the option for a Reset type of Hard (HEAD, index, and working tree updated). Click Reset.

• You will receive a warning about overwriting your local changes. This is what we want since we want to bring a copy of the project back into our local GP1 repository and erase all of your uncommitted local changes (which in this case is all the deleted WolfScheduler files). Click Reset.

• Check that WolfScheduler is now in the Working Tree/ directory of your GP1 repository.

In Git Bash, do the following:

• Change directory to your repository location.
• Enter the command git reset --hard HEAD. This will reset the local repository to the same information as the remote and erase all of your uncommitted local changes (which in this case is all the deleted WolfScheduler files).

Check Your Submission

You should ALWAYS verify that your pushed changes are on the remote repository. You can do this by going to your repository on the GitHub website and making sure that your WolfScheduler project has been pushed to your GP2 repository.

• Log into NCSU’s GitHub
• Select the appropriate organization and repository.
• Verify that your latest commit message is listed and that all pushed files are in the repository.

Verify that your Guided Project 2 Jenkins job is pulling your WolfScheduler from your GP2 repository (this job will start with GP2-. If Jenkins does not recognize your project, please notify the teaching staff via Piazza or the sup list as early as possible to ensure that your project is set up correctly for auto grading.

Check Your Progress

• Make sure that all fields, methods, and constructors are commented.
• Resolve all static analysis notifications.
• Fix test failures.
• Commit and push your code changes with a meaningful commit message. Label your commit with “[Skeleton]” for future you!

Guided Task: Design a Hierarchy

The focus for GP2 is to add Events to the WolfScheduler program. That way users can put items like meals, club meetings, exercise, and other non-course activities on their schedules. For Guided Project 2, you do not need to worry about checking for conflicting activities.

Best Practices: Inheritance

There are two main relationships between classes: composition and inheritance. Composition is a has-a relationship where one object has an instance (or collection) of another object. Inheritance is an is-a relationship where one class is an extension or specialization of another class. When two objects have a common set of fields with some specializations, those objects are candidates for an inheritance hierarchy. You can create a parent class that contains the common fields and each child class can then specialize.

Identifying Common Elements

Use Case 6 and Use Case 7 describes a new type of item that can go on a student’s schedule: Events. Both Course and Event have a common set of attributes: title, meetingDays, startTime, and endTime. These common elements can be stored in a parent class, Activity, and Course and Event can specialize as appropriate for their classes.

By providing a common parent class, you can maintain the user’s schedule as an ArrayList of Activity objects so the schedule can hold both Courses and Events!

UML diagram notations UML uses standard conventions for display of data, methods, and relationships. Many are illustrated in the UML diagram above. Here are some things you should note:

• - OR a red square (empty or solid) in front of a class member means private.
• + OR a green circle (empty or solid) in front of a class member means public.
• Static members (data or methods) are underlined. They also have a small S notation on the left icon.
• Final members (data or methods) have a small F notation on the left icon and the value is typically provided.
• Methods embellished with C are constructors.
• Methods that are declared but not defined (abstract methods or those declared in interfaces) are in italics.
• The names of abstract classes are in italics and there is a small A notation on the class icon.
• Dotted arrows with triangular heads point to interfaces from the classes that implement them.
• Solid arrows with triangular heads go from concrete classes to their parents.
• Solid arrows with simple heads indicate has-a relationships (composition). The containing class is at the tail of the arrow and the class that is contained is at the head. The arrow is decorated with the name and access of the member in the containing class. The arrow is also decorated with the “multiplicity” of the relationship, where 0..1 means there is 1 instance of the member in the containing class and 0..* means there are many (usually indicating a collection such as an array or ArrayList).
• A circle containing an X or cross that sits on the border of a class that contains an inner or nested class, with a line connecting it to the inner class.

You can read this UML class diagram and see the names and types of all the classes and class members that you must create. The method signatures in your program must match the above diagram and provided interfaces exactly for the teaching staff tests to run.

Design Changes and Refactoring

In CSC 216, you’ll have the opportunity to explore creating designs. But for programming projects you will be provided with a teaching staff design that you’re expected to implement. However, in the Guided Projects, you can model design changes and decisions that are made while implementing the WolfScheduler system. These changes are common in practice because of additional understanding and knowledge about a solution as it is implemented.

As you consider design changes, you want to make those changes in slow controlled steps and ensure that you don’t break any old functionality before adding new functionality to the system. You can use refactoring to support making small structural changes to the program that provides a better design and allows for extension and modification of a program while not changing the functionality. You can then ensure that your changes do not alter the functionality by running your unit tests!

In the next section you will walk through using one of Eclipse’s built in refactoring tools that will support the extraction of a super class, Activity, as a first step to the inheritance hierarchy shown in the Figure above.

Guided Task: Extract a Super Class

With the new hierarchy design, now you need to move toward implementation. The common elements are already implemented in Course. You can extract those elements into the parent class. Attempting this extraction manually can be messy and can lead to breaking the code. Luckily, Eclipse provides a refactoring tool that helps with extracting a super class, because developers frequently need to make these types of changes in their code.

Learning Outcomes

• Use the Eclipse refactoring tool to create a super class
• Use automated testing to ensure no regression of functionality

Extract the Super Class

To extract the Activity super class, do the following:

• Open Course in the editor.
• Right click in the Course class in the editor and select Refactor > Extract Superclass. Make sure you are in the curly braces (e.g., {}) that define Course, otherwise the option to Extract Superclass won’t be available!
• Give the superclass the name Activity.
• Select the checkboxes next to the following members of Course
  • UPPER_HOUR
  • UPPER_MIN
  • title
  • meetingDays
  • startTime
  • endTime
  • getTitle()
  • setTitle()
  • getMeetingDays()
  • getMeetingString()
  • getStartTime()
  • getEndTime()
  • setMeetingDaysAndTime()
  • Any private helper methods that you wrote to support the implementation of the above methods (the teaching staff solution has a helper method getTimeString())

• Click Next and verify that you have all the items you need.

• Click Next. Eclipse will provide a warning that the visibility of the method getTimeString() will change due to the refactoring. Since the method is used in Course, the method will need to be public so Course can access it. Warnings like this should be noted for review after the refactoring.

• Click Next again. You’ll see a list of the changes that will be performed as part of the refactoring.

• Click Finish.

Check Compilation

Your code won’t compile after the extraction of the super class. You will have compiler errors in Course and CourseTest. These compilation errors are due to missing parameters when working with methods that were extracted to Activity. The extraction added an extra Course parameter to these methods. They aren’t needed, so let’s remove them.

For example, the method header of Activity.setTitle() should be updated to the following:

1
2
//Remove the Course course parameter
public void setTitle(String title) { 

And Activity.setMeetingDaysAndTime() should be updated to the following:

1
2
//Remove the Course course parameter
public void setMeetingDaysAndTime(String meetingDays, int startTime, int endTime) {

The remaining compilation errors in CourseTest are due to the refactoring adding a Course reference to method calls for setTitle() and setMeetingDaysAndTime(). Remove those extra references. Everything should compile.

What Happens if Everything is a Mess After Trying this Refactoring?

First, don’t panic. We’ve provided the correct code for Activity and Course at this step of the Guided Project.

• Activity.java
• Course.java

You can replace any of the provided method’s implementations with your own.

Run Tests

Run all of your unit tests on the refactored code. Ensure there are no regressions in functionality.

Update Activity and Course

Now that we have extracted the Activity class, we have a few changes that we need to make to ensure encapsulation of Activity information and provide the additional functionality that Activity needs. Complete the following steps.

Make Activity Abstract

Since Activity is a super class of Course and will soon be the super class of Event, there is no need for Activity to be a concrete class. Instead, Activity should be abstract - that means you cannot directly construct Activity objects. Additionally, we’ll be creating some abstract behavior that we Course and Event will define for their contexts.

• Add the abstract keyword to the Activity class header.

1
2
3
public abstract class Activity { 
   ...
}

Make Activity’s Fields Private

When creating the super class, Eclipse set the fields of Activity to protected level access. This means that any sub-class can access the fields directly. However, it also means that another class in the same package can also access the fields directly. To protect your fields, make them private.

Resolve Course Compilation Errors

There will be several compilation errors in Course after you make the fields in Activity private in the hashCode(), equals(), and toString() methods. Do the following to resolve:

• Remove hashCode() and equals(). Now that there is a super class, you should regenerate hashCode() and equals() to use the super class. DO NOT do generate a new equals() and hashCode() yet!
• In toString(), change direct references to Activity fields to use the associated getter methods.

• Run your tests. The tests for Course.hashCode() and Course.equals() will fail. The WolfSchedulerTest.testGetCourseFromCatalog() will also fail because Course.equals() is not yet reimplemented. You’ll fix those shortly!

Create Activity’s Constructor

Activity was created with a parameterless constructor. You want to continue to use the one path of construction paradigm. That means you need a way to construct Activity and its fields.

• Replace the default Activity constructor with one that requires all of the fields. The parameters MUST be in the order of title, meetingDays, startTime, and endTime. Additionally, update the body of the constructor to use the appropriate setter methods for the fields since all of the error checking is completed there.

1
2
3
4
5
    public Activity(String title, String meetingDays, int startTime, int endTime) {
        super();
        setTitle(title);
        setMeetingDaysAndTime(meetingDays, startTime, endTime);
    }

Update Course Constructor

After you add a parameterized constructor to Activity, Course no longer compiles. Now, Course needs to call the parameterized Activity constructor.

• Update Course’s non-compiling constructor to use Activity’s new constructor. Remember, Activity is the parent of Course. To interact with the parent class, you need to use the super reference.

1
2
3
4
5
6
7
8
9
10
    public Course(String name, String title, String section, int credits, String instructorId, String meetingDays,
            int startTime, int endTime) {
        super(title, meetingDays, startTime, endTime);
        setName(name);
        //setTitle(title);  <-- DELETE THIS, called in super
        setSection(section);
        setCredits(credits);
        setInstructorId(instructorId);
        //setMeetingDaysAndTime(meetingDays, startTime, endTime); <-- DELETE THIS, called in super
    }

• Run your unit tests to make sure that everything is still passing (except for the failures discussed above).

Generate hashCode() and equals()

Do the following to add back the hashCode() and equals() functionality in both Activity and Course. Note that you want to generate Activity’s methods first since Course’s method will rely on Activity’s.

• Use Eclipse’s source generation tools to generate hashCode() and equals() in Activity.
• Then use Eclipse’s source generation tools to generate hashCode() and equals() in Course.
• Run your unit tests. They should all be passing again!

Add Abstract Functionality to Activity

Adding events will complicate the display of information in the GUI. There will be some items that Course has that Event will not and vice versa. Creating the array of Strings for display in the GUI should instead be delegated to classes in the Activity hierarchy. You will add two abstract methods that will provide a short and a long version of the array of information to provide to the GUI.

• Add the statement public abstract String[] getShortDisplayArray(); to Activity.
• Add the statement public abstract String[] getLongDisplayArray(); to Activity.

After adding the methods, make sure you comment them. This will help any developers that extend Activity in the future better understand the intention of the methods. The short display array is used to populate the rows of the course catalog and student schedule [UC1, UC3, UC4, UC6]. The full display array is used to display the final schedule [UC9].

Implement Abstract Functionality in Course

After you add these statements, Course will no longer compile. Select the compiler error on the Course class header and use the Quick Fix to add implementations of these two methods to Course.

Implement the methods in Course as follows:

• getShortDisplayArray() returns an array of length 4 containing the Course name, section, title, and meeting string.
• getLongDisplayArray() returns an array of length 7 containing the Course name, section, title, credits, instructorId, meeting string, empty string (for a field that Event will have that Course does not).

Extended Course Unit Testing

Using the WolfScheduler requirements along with the provided ExtendedCourseTest JUnit tests, you will finish implementing the Course class to pass the tests!

Download the provided ExtendedCourseTest JUnit tests and put it in the edu.ncsu.csc216.wolf_scheduler.course package in the test/ folder. If you do this via the file system, right click on the project in Eclipse and refresh so the test file is recognized by Eclipse. You can now run the tests. Fix any failures.

Keep Both Test Files

Keep both CourseTest.java and ExtendedCourseTest.java in your project. CourseTest contains the original GP1 tests that verify basic Course functionality, while ExtendedCourseTest contains additional tests for the new Activity hierarchy features (like getShortDisplayArray() and getLongDisplayArray()). Both test files should pass when you submit.

Comment Activity and Course and Fix Static Analysis Notifications

Update all your Javadoc for Activity and Course. Make sure you update all references to Course in the comments for Activity.

Overridden methods much also be commented to describe the specifics in the overridden implementation. Note that Checkstyle will NOT generate notifications if you’re missing comments on overriden methods. But we do check for that when grading!

Now is a great time to make sure that CheckStyle, PMD, and SpotBugs are all active on your project. Right click on the WolfScheduler project and select Properties. You can select each tool and make sure it is turned on. Resolve all the notifications.

Check Your Progress

Complete the following tasks before pushing your work to GitHub.

• Make sure that all fields, methods, and constructors are commented.
• Resolve all static analysis notifications.
• Fix test failures.
• Commit and push your code changes with a meaningful commit message. Label your commit with “[Refactoring]” for future you!

Independent Task: Create Event

Now you have created Activity without any regressions, you can create the Event class as a second child class of Activity.

Learning Outcomes

• Create a new class that extends and existing class
• Implement abstract methods
• Run unit tests

Implement Event Class

Create a new Java class called Event in the edu.ncsu.csc216.wolf_scheduler.course package of the WolfScheduler project. Select the following options:

• Browse for Activity as the Superclass
• Check the option to creating stubs for “Inherited abstract methods”.
• Check the option to “Generate comments”.

Implement Event State

The Event class will not yet compile because we do not yet call Activity’s constructor. Before creating a constructor for Event, we want to implement the field for Event. This way we can integrated the field when generating our constructor.

Event knows about one other item in addition to those provided by Activity:

• a String called eventDetails.

The field should be private.

Generate the getter and setter for the field.

Implement Event() Constructor

Generate an Event() Constructor using Event’s fields.

The constructor should have five parameters (title, meetingDays, startTime, endTime, and eventDetails). This is because the Event constructor also needs the parameters to construct the parent Activity. Update the lines that set the fields to call the corresponding setter methods as a common path of error checking.

1
2
3
4
    public Event(String title, String meetingDays, int startTime, int endTime, String eventDetails) {
        super(title, meetingDays, startTime, endTime);
        setEventDetails(eventDetails);
    }

Implement Event.setEventDetails()

The setEventDetails() method should throw an IllegalArgumentException if the eventDetails parameter is null. Since eventDetails are optional, the field may contain an empty string. The IllegalArgumentException message should be “Invalid event details”.

Implement Event.getShortDisplayArray()

The getShortDisplayArray() should return a String array of length four. The first two values should be empty strings since Event doesn’t have a name or section. The last two values should be the title and the meeting string.

Implement Event.getLongDisplayArray()

The getLongDisplayArray() should return a String array of length seven. The first two values should be empty strings since Event doesn’t have a name or section. The third value is the title followed by two values with empty strings. The last two are the meeting string and eventDetails.

Override toString()

Right click in the editor and select Source > Override/Implement Methods. Check the boxes to override toString() (which is under Object).

Implement toString() to produce a comma separated string that meets the description in [UC 10].

Overriding Other Methods?

You don’t need to override the equals() and hashCode(). An Event should be considered the same if the title and the meeting information is the same; the details aren’t needed for equality. Therefore, you don’t need to override these methods. Event inherits Activity’s equals() and hashCode() methods.

Test Event

We have provided tests for Event.

Add EventTest to the test folder in the edu.ncsu.csc216.wolf_scheduler.course package.

Oh no! Two failing tests!

• testSetMeetingDaysAndTimeInvalid() has a failing test with the meeting days string of “A”. Unlike Courses, Events cannot have a meeting day string of “A”.
• testSetMeetingDaysAndTimeValid() has a failing test with the meeting days string of “UMTWF”. The characters ‘S’ and ‘U’ are valid for Events; they can occur on Saturdays or Sundays.

You will eventually correct the code causing that error in the Debugging section, which comes next.

All of your other tests should pass now, however. If they do not, you will need to debug those tests. It may be helpful to hold on fixing them until after we discuss the debugger.

Comment Event and Fix Static Analysis Notifications

Complete the following tasks:

• Update all your Javadoc for Event. Overridden methods much also be commented to describe the specifics in the overridden implementation. Note that Checkstyle will NOT generate notifications if you’re missing comments on overriden methods. But we do check for that when grading!
• Resolve all static analysis notifications.

Check Your Progress

Complete the following tasks before pushing your work to GitHub.

• Make sure that all fields, methods, and constructors are commented.
• Resolve all static analysis notifications.
• Fix test failures.
• Commit and push your code changes with a meaningful commit message. Label your commit with “[Implementation]” for future you!

Guided Task: Run the Debugger

You have two failing test cases! Yay! This means that we have a concrete example of where our code doesn’t work. And we can use the failing test case to debug our code, find the fault, and then fix it!

We’ll start with the failure in testSetMeetingDaysAndTimesInvalid(). The requirements [UC6] tell us that the student would enter the days of the week (Sunday through Saturday). That means the meetingDays value of “A” is not valid for Event. The test is failing because you CAN set the meetingDays to “A”. It’s time to use the debugger to find where you need to fix your code.

The debugger is a tool that steps through your program a statement at a time. You can follow the flow of control into a called method. Additionally, the debugger provides a view into the values of variables as the code is executing. It’s a very helpful tool for finding and fixing faults in your code.

Learning Outcomes

• Use the debugger to fix a failing test.

Set a Breakpoint

When you debug code, you need to stop the execution so you can then step through the program. A breakpoint pauses the execution of the program. Then you can view information about the program’s state.

When a test fails, you should put a breakpoint at the line of the code under test that you think is causing the failure. You can determine this by selecting the failing test and investigating the failure trace as shown for the testSetMeetingDaysAndTimesInvalid() test failure below. From this failure, we can see that for the input of “A” we expected an IllegalArgumentException, but the exception was not thrown. By clicking the first line labeled “at”, we can go the specific line of code that caused the test failure.

From this failure, we can see that for the input of “A” we expected an IllegalArgumentException, but the exception was not thrown. By clicking the first line labeled “at”, we can go the specific line of code that caused the test failure. Our failure is highlighted at line 126 (this may be slightly different in your local environment, which is probably ok unless you edited your tests files in a more significant way than adding blank lines…). This failure is in a method that is testing invalid meeting information. Events cannot be arranged, so the “A” meetingString is invalid. In this test, we are expecting an exception to be thrown, but it was not!

From there, we can determine the best place to put a break point. In this example, we are calling a setter as part of the test case. Since setters change object state, we should start with the setter closest to the failure; that likely lead to the failure. Put a breakpoint at the line of the failing test by double clicking in the blue bar to the left of the line numbers. This blue bar is called the “gutter”.

Run the Program through the Debugger

With debugging, you select the Debug option rather than the Run option. You can run in debug mode by right clicking on the test/ folder, a package, or a specific class, and selecting Debug As > JUnit Test. There is also a debug button on the top level tool bar. Select Debug to run the last run configuration in debug mode or select the arrow to create a new run configuration to debug.

However, when debugging, I like to focus on a single failure at a time! This helps narrow my debugging session and removes having to hit a breakpoint multiple times just to get to the failure that I’m interested in debugging. That means I select the specific test failure I want to debug in the JUnit view. And for parameterized tests, you can select the specific row that you’re interested in debugging. To debug the test failure in testSetMeetingDaysAndTimesInvalid(), right click on test 11 under the testSetMeetingDaysAndTimesInvalid() label and select Debug.

You may get a message about switching perspectives - this is okay. If you check the “Remember my decision,” you will not see this dialog again.

The Debug Perspective provides several views to help you with the task of debugging your code.

• Debug shows the live stack trace of methods. The figure illustrates the stack trace in execution of EventTest.testSetMeetingDaysAndTimeInvalid(). If other programs were running at the same time, you would see them here.
• Stepping Buttons are in the top tool bar. The provide the ability to restart execution, stop execution, and step through the code. We’ll cover this in more detail shortly.
• Variables shows the values of all the variables that have been declared. If your breakpoint stops before a variable’s declaration, that variable will not appear in the list.
• Breakpoints shows the locations of all your breakpoints in the code (you can have many breakpoints).
• EventTest.java shows where you are in the code at the time of the breakpoint. The arrow and highlighted text let you know where you are in the code.

Debugger Controls

The main Eclipse toolbar provides buttons for working with the debugger. There are 7 buttons in the toolbar:

• Resume: resumes the current execution from the given program point
• Suspend: pauses an execution
• Stop: stops the debugging execution. Always stop your debugging executions or you’ll use up a lot of system memory!
• Disconnect: disconnects the debugger
• Step Into: steps into a method call
• Step Over: steps over a method call without going into the details of the method
• Step Return: finishes execution of the current method and returns to the caller

Step Through a Program

You can use the debugger to determine what is happening in a program and find an underlying bug. By exploring the program, you are likely to have a better understanding of the flow of control and identify where an implementation doesn’t meet the requirements.

The line of code we’re investigating is complex. Let’s walk through it first before we start debugging:

1
2
Exception exception = assertThrows(IllegalArgumentException.class,
				() -> event.setMeetingDaysAndTime(meetingString, startTime, endTime));

This line is asserting that an IllegalArgumentException (our expected result) will be thrown when we call event.setMeetingDaysAndTime(meetingString, startTime, endTime), which is the method call that will lead to our actual result. For this specific failure, the meetingString is “A”, startTime is 0, and endTime is 0, which we can see in the Variables view. If the IllegalArgumentException is thrown, it will be assigned to the exception reference and then we can check that the correct message was provided to describe the reason for throwing the exception.

Typically at this point, we would step into the method call at the program statement. However, lambda expressions will take you through a lot of the Java API. Since we know what method we want to go to, switch to Activity.setMeetingDaysAndTime() and add a breakpoint at the first statement. Then you can click the Resume button to until you reach the first line of setMeetingDaysAndTime() bypassing all the Java API calls.

Now, we can explore the method by stepping over the program statement. Continue stepping through the method with the Step Over button. You reach the end of the method for the assignment to the meetingDays field without throwing an exception!

At this point you can either Resume or Stop the test run. You know there’s a problem in Activity.setMeetingDaysAndTime().

Debug the Program

The implementation of setMeetingDaysAndTime() in Activity is the implementation extracted from Course. There isn’t an implementation of setMeetingDaysAndTime() that supports Event specifics! You need to make a decision about how to best handle the differences between Course and Event for setMeetingDaysAndTime(). A common implementation in Activity will not work.

The solution is to have Course and Event override the setMeetingDaysAndTime() method. Course and Event will handle their own checks on meetingDays appropriate for their requirements. Then they will pass meetingDays, startTime, and endTime to Activity.setMeetingDaysAndTime() for the common time checks and assignment of the fields.

• Keep the common checks for times (e.g., valid military time) in Activity. You can optionally also keep the checks that meetingString isn’t null or empty.
• Override setMeetingDaysAndTime() in Course and ensure that [UC1] is satisfied. You will need to check that meetingString is not null or empty at the start of the overridden method. Then let Activity.setMeetingDaysAndTime() handle the common checks and final assignment.
• Override setMeetingDaysAndTime() in Event and ensure that [UC6] is satisfied. You will need to check that meetingString is not null or empty at the start of the overridden method. Note that for the meetingDays, string “U” represents Sunday and “S” represents Saturday. The other days of week characters are the same as Course. Any other character, including “A”, is invalid. Then let Activity.setMeetingDaysAndTime() handle the common checks and final assignment.

Overriding Activity.setMeetingDaysAndTime() in Event should resolve both test failures. Course tests should continue to pass.

Run Tests

Run your tests! If any are still failing, use the debugger to help you find the problem.

Switch Back to the Java Perspective

Once you’re done with debugging, you should switch back to the Java Perspective. Click the icon with a package, green circle, and purple circle with a J on it in the upper right corner to switch to the Java perspective.

Comment Event and Fix Static Analysis Notifications

Complete the following tasks:

• Update all your Javadoc for Course and Event. Overridden methods much also be commented to describe the specifics in the overridden implementation.
• Resolve all static analysis notifications.

Additional Resources on the Debugger

This was a very brief overview of using the debugger. If you would like more information, please see the Eclipse Debugger Tutorial.

Check Your Progress

Complete the following tasks before pushing your work to GitHub.

• Make sure that all fields, methods, and constructors are commented.
• Resolve all static analysis notifications.
• Fix test failures.
• Commit and push your code changes with a meaningful commit message. Label your commit with “[Debug]” for future you!

Guided Task: Create ActivityRecordIO

CourseRecordIO handles reading course records from a file to create a course catalog and writing Courses to a file. Now that you have Events that should also be written to an output file (as per [UC10], you need to create a new IO class to handle writing Activity objects.

Learning Outcomes

• Refactor file I/O functionality

Create ActivityRecordIO Class

Create a new Java class called ActivityRecordIO in the edu.ncsu.csc216.wolf_scheduler.io package of the WolfScheduler project. Do not create the constructor or any methods in ActivityRecordIO.

Move writeCourseRecords() to ActivityRecordIO

Complete the following steps to move writeCourseRecords() from CourseRecordIO to ActivityRecordIO.

• Open CourseRecordIO in the editor.
• Select the writeCourseRecords method name in the editor. You only want to select the method name.

• Right click on the writeCourseRecords method name and select Refactor > Move.
• Browse for ActivityRecordIO. Uncheck the options to keep original member as delegate to moved member.

• The method is now in ActivityRecordIO. WolfScheduler and CourseRecordIOTest have been udpated with the change.
• Refactor the method name in ActivityRecordIO. Select the method name, right click on the method and select Refactor > Rename. Enter writeActivityRecords and click Enter.
• Update the generic parameter of the ArrayList to be Activity instead of Course.
• Update the local variables in the for loop. You can use the keyboard short cut of Alt + Shift + R to do the rename refactoring.
  • Change c to a
  • Change courses to activities
• Delete the import for Course since it is no longer needed.

At this point, there will be a compilation error in WolfScheduler.exportSchedule(). That’s ok. We’ll fix it later.

The compilation error in CourseRecordIOTest we’ll fix after you check that ActivityRecordIO is complete.

After you are done, ActivityRecordIO should look like the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
package edu.ncsu.csc216.wolf_scheduler.io;

import java.io.File;
import java.io.IOException;
import java.io.PrintStream;
import java.util.ArrayList;

import edu.ncsu.csc216.wolf_scheduler.course.Activity;

/**
 * Writes activities to file.
 * @author Sarah Heckman
 */
public class ActivityRecordIO {

    /**
     * Writes the given list of Courses to 
     * @param fileName file to save to
     * @param activities list of course to save
     * @throws IOException if the file cannot be written
     */
    public static void writeActivityRecords(String fileName, ArrayList<Activity> activities) throws IOException {
    	PrintStream fileWriter = new PrintStream(new File(fileName));
    	
    	for (Activity a : activities) {
    		fileWriter.println(a.toString());
    	}
    	
    	fileWriter.close();
    }

}

Update CourseRecordIOTest

There is a call to ActivityRecordIO in CourseRecordIOTest that is not compiling. This is because we changed the parameter type from an ArrayList of Courses to an ArrayList of Activitys. We’ll need to update the ArrayList generic type in our test.

Update the first line of the test method to ArrayList<Activity> activities = new ArrayList<Activity>();. You’ll need to import Activity for the test to compile. When changing the variable name, rename with the refactoring tool.

Run Tests

Run your tests! You’ll get a warning because WolfScheduler is not compiling, but you can run anyway to make sure that CourseRecordIOTest passes. If any are still failing in the course or io packages, use the debugger to help you find the problem. For now, the WolfScheduler tests may fail due to compilation errors and that’s ok.

However, your suite of tests is not sufficient to evaluate if events are correctly written to file. Create a class ActivityRecordIOTest the edu.ncsu.csc216.wolf_scheduler.io package of the test/ folder in the WolfScheduler project. Copy in the provided ActivityRecordIOTest code into ActivityRecordIOTest. Create a new text file in the test-file/ directory called expected_activity_records.txt and copy the provided expected_activity_records.txt. Run the tests. Ensure they all pass!

Comment ActivityRecordIO and Fix Static Analysis Notifications

Complete the following tasks:

• Update all your Javadoc for ActivityRecordIO.
• Resolve all static analysis notifications.

Check Your Progress

Complete the following tasks before pushing your work to GitHub.

• Make sure that all fields, methods, and constructors are commented.
• Resolve all static analysis notifications.
• Fix test failures.
• Commit and push your code changes with a meaningful commit message. Label your commit with “[Implementation]” for future you!

Independent Task: Update WolfScheduler

There are several updates required for WolfScheduler to work with the Activity hierarchy.

Learning Outcomes

• Refactor WolfScheduler to use Activity polymorphically.

Update WolfSchedulerTest

Download the updated WolfSchedulerTest. Overwrite anything in the existing file. Note that the tests will initially not compile. You can use the tests to help you drive your development. The details of the changes are outlined in the following steps.

Update WolfScheduler

There are several tasks that you will need to complete to update WolfScheduler to pass the provided tests.

Update schedule Field

The first change is to update the generic type of the schedule ArrayList. A schedule can now contain Events. Update the generic type to Activity so you can store both Courses and Events in the schedule. You’ll need to import Activity and the construction of schedule in WolfScheduler.WolfScheduler().

Also update the generic type when constructing the schedule object in the WolfScheduler constructor.

There will be additional compilation issues that you will resolve in the next steps.

Update addCourseToSchedule()

Since schedule’s type is now Activity rather than Course, the reference returned from a call to .get() cannot be assigned to a Course reference without a cast. Casting should be avoided when it makes the class less cohesive. In this case, that means WolfScheduler should focus on adding Activity objects rather than casting to figure out if an object is a duplicate or not. To avoid casting in WolfScheduler, we’ll create a new abstract method in Activity that will be implemented in Course to check for duplicate Courses and in Event to check for duplicate Events.

The check that is done at this portion of the code is to see if the Course to be added is a duplicate of a Course already in the schedule – see [UC4]. [UC6] describes a similar situation for Event. The idea of duplicate Courses and Events is different from the definition of equality in the equals() methods. Keeping a full comparison is beneficial for testing and may be useful in other situations. So now add a new abstract method to Activity that both Course and Event can implement. The method will check if some other Course or Event is a duplicate.

• Add the abstract method public abstract boolean isDuplicate(Activity activity); to Activity.
• Implement the in Course.isDuplicate()
  • You will need to check if the parameter is an instance of Course and cast to check Course’s fields. But this is similar to how the equals() method works and fits the Course abstraction of identifying a duplicate of itself.
  • Two Courses are considered duplicates if they have the same name.
• Implement the method in Event.isDuplicate()
  • You will need to check if the parameter is an instance of Event and cast to check Events’s fields. But this is similar to how the equals() method works and fits the Event abstraction of identifying a duplicate of itself.
  • Two Eventss are considered duplicates if they have the same title.
• Update WolfScheduler.addCourseToSchedule() to use the new isDuplicate() method.
  • Hint: you’ll need to get the Course to add from the catalog before comparing to the Activitys in the schedule.
• Comment all your updates!

Reference: GP2 Design

See the Guided Project 2 Design for details on where methods like isDuplicate() should be implemented and expected method signatures.

Update removeCourseFromSchedule()

removeCourseFromSchedule() requires a larger refactoring. The remove functionality is the same for both Courses and Events. However, the current removeCourseFromSchedule() method has parameter specific to Course. By updating the method signature, you can update the method to handle any object in the Activity hierarchy.

• Select the removeCourseFromSchedule method name. Right click and select Refactor > Change Method Signature.
• In the resulting dialog, remove the two existing parameters and add a new parameter of type int called idx. The default value (used for replacement of the parameters in the refactoring) should be -1. Make sure the “Keep original method as delegate to change method” is unchecked. Click OK.

• The dialog will warn of compilation errors due to the change. We’ll fix those in a moment. Click Continue.
• Rename removeCourseFromSchedule() to removeActivityFromSchedule(). Use Alt+Shift+R for the keyboard shortcut.
• Fix the compilation errors so that the removeActivityFromSchedule() method compiles. The parameter idx is the index of the Activity you want to remove from the schedule. Note that the fix can be completed by removing the for loop and delegating to the ArrayList’s remove(idx) method. You’ll want to catch any IndexOutOfBoundsExceptions and return false.

Update resetSchedule()

Fix the resetSchedule() method so that the method compiles and passes its test case.

Update getCourseCatalog()

Update getCourseCatalog() to include a fourth column that provides the meeting string information.

You created abstract methods in Activity that support returning an array for Courses and Events. Refactor getCourseCatalog() to use the getShortDisplayArray(). Note that instead of assigning the cells individually, you can use the Activity.get*DisplayArray() method to assign the result at row i. And example is shown below for getCourseCatalog().

1
2
3
4
5
6
7
8
public String[][] getCourseCatalog() {
	String [][] catalogArray = new String[catalog.size()][4];
	for (int i = 0; i < catalog.size(); i++) {
		Course c = catalog.get(i);
		catalogArray[i] = c.getShortDisplayArray();
	}
	return catalogArray;
}

Update getScheduledCourses() and getFullScheduledCourses()

Do the following to update these methods:

• Refactor getScheduledCourses() to getScheduledActivities()
• Update getScheduledCourses() to use getShortDisplayArray() similar to `getCourseCatalog()
• Refactor getFullScheduledCourses() to getFullScheduledActivities()
• Update getFullScheduledCourses() to use getLongDisplayArray() similar to `getCourseCatalog()

Remember that the short display array has 4 columns and the long display array has 7 columns.

Implement addEventToSchedule()

The functionality for adding a Course is separate from adding an Event. Implement the addEventToSchedule() method that is called in the WolfSchedulerTest class. The method headers should be:

1
2
3
public void addEventToSchedule(String eventTitle, String eventMeetingDays, int eventStartTime, int eventEndTime, String eventDetails) {
	
}

If the new Event is a duplicate of an existing Event in the schedule, an IllegalArgumentException should be thrown with the message “You have already created an event called [event title]”.

Run Tests

Run your tests! If any are still failing, use the debugger to help you find the problem.

Comment WolfScheduler and Fix Static Analysis Notifications

Complete the following tasks:

• Update all your Javadoc for WolfScheduler.
• Resolve all static analysis notifications.

Check Your Progress

Complete the following tasks before pushing your work to GitHub.

• Make sure that all fields, methods, and constructors are commented.
• Resolve all static analysis notifications.
• Fix test failures.
• Commit and push your code changes with a meaningful commit message. Label your commit with “[Implementation]” for future you!
• Check Jenkins results for a green ball! Fix any Jenkins issues.

Independent Task: Update WolfSchedulerGUI

WolfSchedulerGUI should be updated to interact with the updated Event functionality.

Learning Outcomes

• Update WolfSchedulerGUI

Update WolfSchedulerGUI

Copy the code from WolfSchedulerGUI.java into your Eclipse file. Overwrite the entirety of the old file.

Run Unit Tests

Run your tests! If any are still failing, use the debugger to help you find the problem.

The tests and resources files are listed below if you would like to ensure that you have the correct versions.

Test Classes (in test/ directory):

• CourseTest.java
• ExtendedCourseTest.java
• EventTest.java
• CourseRecordIOTest.java
• ActivityRecordIOTest.java
• WolfSchedulerTest.java

Test Files (in test-files/ directory):

• course_records.txt
• expected_activity_records.txt
• expected_course_records.txt
• expected_empty_export.txt
• expected_schedule_export.txt
• invalid_course_records.txt
• starter_course_records.txt
• README.txt

Run System Tests

Run WolfSchedulerGUI and ensure that you pass the new and updated suite of system tests for the WolfScheduler project. As part of running your tests, you must report the actual results of execution. Download the document as a Word document by select File > Download > Microsoft Word in Google Drive. Create a new folder in your WolfScheduler project called project_docs by right clicking on WolfScheduler and selecting New > Folder. Save your black box test plan as a Word document (*.doc or *.docx) in the project_docs folder. As you run each test, report the results of execution in the black box test plan in the actual results column. DO NOT record, “Passed” or “Failed.” Instead, describe the results, similar to the provided Expected Results.

Make sure all your black box tests pass! However, if you run out of time, report the actual results of execution - EVEN IF THEY ARE FAILING! You’ll earn some points on the system test portion of the grading rubric for reporting actual, failing results.

Check GitHub for System Test Plan

Check that your System Test Plan is actually pushed to the remote GitHub. If you saved the file to your project via the file system and pushed using Eclipse, Eclipse likely did not know about the new file. Refresh your project in Eclipse by right-clicking on the project and selecting Refresh. You should then see the *.docx file in your project_docs directory and in the Git Staging view.

Also, make sure you have the System Test Plan in the correct loction so the PTFs can find it quickly during grading!

Check Your Progress

Complete the following tasks before pushing your work to GitHub.

• Make sure that all fields, methods, and constructors are commented.
• Resolve all static analysis notifications.
• Fix test failures.
• Commit and push your code changes with a meaningful commit message. Label your commit with “[GUI]” and “[Test]” for future you!
• Check Jenkins results for a green ball! Fix any Jenkins issues.

Independent Task: Submit Project

There are a few tasks that you must complete to wrap up Guided Project 2 for grading.

Learning Outcomes

• Run static analysis tools and fix notifications

Run WolfSchedulerGUI and ensure that you pass the extended suite of system tests for the WolfScheduler project.

The Black Box Test Plan is stored on Google Drive. As part of running your tests, you must report the actual results of execution. Download the document as a Word document by select File > Download > Microsoft Word in Google Drive. Create a new folder in your WolfScheduler project called project_docs by right clicking on WolfScheduler and selecting New > Folder. Save your black box test plan as a Word document (*.doc or *.docx) in the project_docs folder. As you run each test, report the results of execution in the black box test plan in the actual results column. DO NOT record, “Passed” or “Failed.” Instead, describe the results, similar to the provided Expected Results.

Make sure all your black box tests pass! However, if you run out of time, report the actual results of execution - EVEN IF THEY ARE FAILING! You’ll earn some points on the system test portion of the grading rubric for reporting actual, failing results. –>

Run Static Analysis Tools

Run SpotBugs, PMD, and CheckStyle on your code (if you haven’t already) and remove any notifications.

Generate Javadoc

If you haven’t been commenting your code all along, go back and comment your code with JavaDoc. All classes, methods, and fields should be commented. If you have been commenting as you have implemented the Activity hierarchy, go back and double check that the comments are up to date for the implemented functionality.

Make sure you include comments for overridden method that describe why the override was important.

Generate JavaDoc for WolfScheduler. You may want to delete the existing doc/ folder before generating a new one to ensure that all Javadoc is updated. Double check that everything was generated!

Continuous Integration and Automated Grading

As with Guided Project 1, and all programming assignments for CSC 216/217, we are using Jenkins as an automated grading and feedback system. Check your Jenkins results and use them to estimate your grade against the Guided Project 2 rubric.

Final Tasks

Before you complete your final submission to GitHub, you should ensure the following:

• You have met the requirements and design for the WolfScheduler project, except for the conflicting activities functionality.
• You have a green ball on Jenkins. (No test failures and no static analysis notifications.)
• All JUnit tests pass with a green bar (0 errors). There should be no modifications to the teaching staff tests.
• All System Tests pass and actual results are reported.
• There are no SpotBugs notifications.
• There are no PMD notifications.
• There are no CheckStyle notifications.
• All code is commented with meaningful comments.
• JavaDoc webpages are generated with the latest comments.
• AI usage documented in README.md (see AI Usage Documentation below).
• That you meet all rubric items for the assignment.

Make sure that all code and other assignment deliverables are pushed to GitHub by the assignment deadline. There are deductions for any late work up to 48 hours.

Required Deliverables for GP2

Your GP2 submission should include the following in your GitHub repository:

• All source code for the WolfScheduler project (including the new Activity and Event classes)
• All test files (CourseTest.java, ExtendedCourseTest.java, EventTest.java, WolfSchedulerTest.java, etc.)
• Generated Javadoc in the doc/ folder
• System Test Plan (.docx file) in project_docs/ folder with actual results reported
• Updated README.md with AI usage documentation

Note: You do not need to remove any GP1 artifacts (like the GP1 System Test Plan) from your repository. The graders will look for the GP2-specific deliverables.

AI Usage Documentation

As stated in the syllabus, the use of AI assistants (e.g., ChatGPT, Claude, Copilot) is permitted for programming assignments. All AI assistance MUST be documented in your README.md file. Include for each use:

• The AI tool used
• The prompt given
• A summary of the AI response
• How you verified the AI response
• How you used the AI response in your solution

Undocumented AI usage is a violation of academic integrity. Include an AI documentation section in your README.md even if you did not use AI tools (state that no AI tools were used).

Grading Rubric

Your Wolf Scheduler Guided Project 2 will be evaluated on the following items:

Overall Rubric

Phase	Grade Item	Points	Details
	Teaching Staff JUnit Tests	40	Pass all of the provided JUnit tests.
	Teaching Staff System Tests	45	There are 15 system-level black box tests. All tests are worth 3 points for a total of 45 points. For each test, 2 points are for passing the test and 1 point is for reporting the actual results of running the test on YOUR program - even if the test if failing!
	Javadoc Contents	5	See the Javadoc rubric, below. The rubric will be applied per class and will be averaged by the number of classes.
	Javadoc Generation	5	Javadoc tool was used to generate the HTML version of the API, which matches the current version of the in-code Javadoc.
	Style	5	Any PMD, CheckStyle, or SpotBugs Scary or Scariest notifications will result in a one point deduction, up to the available points.
	Prerequisite Review	10	Completion of the activity will earn the points.
	Total Points	110

Deductions

JavaDoc Rubric

Check Your Progress

Complete the following tasks before pushing your work to GitHub.

• Make sure that all fields, methods, and constructors are commented.
• Resolve all static analysis notifications.
• Fix test failures.
• Commit and push your code changes with a meaningful commit message. Label your commit with [Test], [Static Analysis], [Fix], [GUI], [Documentation] as appropriate for the change and for future you!
• Check Jenkins results for a green ball! Fix any Jenkins issues.