Roommate Tools

The four of us, Matt B., Raymond G., William V., and Khoi D., set out to create a useful tool for university students. We ended up developing Roommate Tools, a practical application whose primary concern is to allow students to find potential roommates.

Abstract

We first require that students create an account, select their school, and enter a host of roommate preferences as well as room preferences. The student profile contains several properties such as: noise level, wake time, sleep time, utilities, rent amount, etc. These allow the student to make an informed decision when reviewing the profiles of their potential roommate matches to best fit their unique lifestyle. In addition to searching potential roommate candidates, we included access to several other useful functions. The gpa calculator can be used to determine your gpa after each semester. The class grade calculator could be used to calculate your current class score to see if improvement is needed. Finally, there is the class path function, where students input their class schedule order using the key provided, and the program will return the shortest path to each class, along with the total walking distance in miles. The roommate lookup is limited to one university right now; however, it could be expanded to many schools if needed. There are also a few other notable areas of improvement. In particular, we are limited to storing accounts in a simple file, although we could store account data in a server given more time for development. Ultimately, however, we believe we accomplished the goal of this project: to provide university students some of the tools they may need in order to succeed in their academic career.

Introduction

The core of this project consists of what we term a “back-end” and a “front-end.” We also included extra features, which will be covered in the body of this report. Matt B. wrote most of the back-end, including the first file of the project, Student.java. Student is a class which is designed to represent a user, and it stores his or her preferences, as well as personal information. The primary function of the student class is to generate a queue of other students who are what we term “matches.” These other students will have the most similar preferences within their own account. The queue is sorted by selection sort for the most matches to the least, and only students who share the same school are able to enter the queue. Later, file input and output capability was added, so that student could be read from a simple account file, and a reference was stored to the currently logged in student. School was the other core class of the back-end, which stored the information of the buildings and their associated students. Other notable mentions of the back-end included the Huffman Tree and Password files. The Huffman tree used a data structures extensively, including a stack, map, tree, and “group” (a custom data structure). This algorithm followed the pen-and-paper method of constructing a Huffman Tree. This Huffman Tree was used to return a map of characters associated with String values composed of 0s and 1s (bit-strings) which were used in password creation. The password file combined the Huffman encodings of every character of the password string with the inherent ASCII values to create a checksum (or what we refer to as, a one-way encryption). Using similar file input and output, when a student logs in, the password he or she enters is run through the same algorithm, and compared against the stored checksum value. This determines success at logging in. This covers mosts part of the back-end, but we have also provided a graphical user interface to allow easy access within the application (which we refer to as the “front-end”).

The front-end was written as a joint effort between Raymond G. and William V.. Using Swing and carefully working with the back-end, they implemented various GUIs to allow for input and output within the application. They follow largely sequentially as so: In the beginning of the project, we run RoommateFinder.java, which acts as the driver for the application. Then, we instantiate the JFrame of the Sign In page. From here, the user is able to input their username and password into the respective JTextField and JPasswordFields. If the user chooses to log in with an existing account, the LogInGUI.java class will first read through an existing user text file that contains previous students’ associated usernames and encrypted passwords. The SignInGUI will then call a validation method that calls the Password class to encrypt the inputted password, which will finally be checked against the existing user text file. If the inputted information is not valid, a red error - namely a JLabel will appear, notifying the user they have inputted an invalid account thus restricting the user from moving beyond the LogIn page. If the login is successful, the user will be taken to the MainMenu page, where they have access to either the student tools or the display of their unique student matches. If the user was to click “Display Matches,” a matching procedure would be initialized. The GUI would call the DisplayMatchesGUI and StudentMatch, which will read from a file containing the student and their attributes. After instantiating the students appropriately, the method will then call the Student class’s match method, which will initialize a JList with a queue of students, ordered from the closest possible match to the least. By highlighting a name and clicking “get information” a pop-up window will appear, displaying all the attributes of that unique student. It is from here that you can browse various students who are also looking for a roommate. If the user had chosen to make a new account, they would click “sign up” and be taken to a page generated by the PasswordSetupGUI asking them to enter their name and their desired password. The name will be written to a file, while the password will be encoded through the same procedure described above and the encrypted version written to the file. Continuing the signup process, the next page will be the StudentInfoGUI and RoomPreferencesGUI, where all the relative information will be written out to a file. These GUI classes contain various student preferences, such as the major, sleeping pattern, and other important attributes of the student. Once they are done signing up, the new user can log into the account they created, where their own unique list of students will be displayed. The front and back ends come together in the ReadFile and RoommateFinder classes to complete the program. Furthermore, the “front end” also created various Student Tools, which will be discussed later in the report.

Method

As aforementioned, the Student class holds properties that a user inputs at sign-up for an account. The core functionality is to generate matches with other potential roommates based on preferences. These are stored in a queue in descending order by number of matching preferences. Also contained is a generate method, which will create random students for testing purposes. The ReadFile method will read from a text file containing all users and their properties and instantiate students therefrom. They will be used later to find matches. The School class holds all of the students within objects of the inner Building class. These organize students and allow for match making. Each building has a predetermined capacity.

The HuffmanTree class will take in a string, get the counts for each character, and create a string representation of original input with 0s and 1L. This is done following the pen-and-paper method using the data structures mentioned in the introduction. These encodings are made use of in the Password class. The Password class has only one method, to return a password based on two strings. The first is the entered password, and the second is the confirmation string, which must match. This will then use the aforementioned Huffman encodings by replacing every character in the original string with its Huffman encoding. Then, the binary-to-decimal algorithm is used to convert this string to a numeric base 10 value. This value is combined with ASCII values (the first and last characters’ numerical values are added) and this is returned as the final checksum (or one-way encryption). Now that we have spoken in detail about the “back end”, let’s discuss the “front end” namely Student Tools and the signing up process in more detail.

StudentToolsGUI contains three JButtons, that, when clicked will call for the creation of a new JFrame (the one respective to the JButton the user selected) without disposing of the current JFrame. By clicking on any of the three choices, an action listener that has been added to the buttons will initiate that respective JFrame.

The first student tool that was completed was the ClassPath. The main method of the ClassPath class takes in an arraylist of numbers and using a for loop, will call Dijkstra’s algorithm with a different starting position every time. Going into Dijkstra's method, several arrays are made and assigned default variables and sizes. The algorithm will start at a certain spot in the arrays and iterate through finding the distances from the start to end, overwriting if the distance is shorter. After finding all path costs to each building, the method calls printSolution, which will format the output and get the path to each location desired. This process is repeated until the end of the arraylist where it will print out the total journey length in the getTotal method. Also, it will print the “path” taken when the getPath method is invoked.

The ClasspathGUI is the front-end of the ClassPath, where users may enter their class schedule. Using the provided key in the same form as picture below, the user will enter the corresponding numbers with a space in between. After pressing “Go”, the input would be read by the GUI, placed into an arraylist, validated as legitimate input and delivered to the ClassPath class. . The output will be formatted and returned to the ClassPathGUI, where the result will be displayed to the student. Note that if the “clear button” is pressed on any of the student tools applications, the entered fields will be reset back to their respective fields and labels. In this case, the labels are empty until “Go” is selected and the input is validated, at which point the labels will be set to the same output as the ClassPath’s algorithm.

The second student tool that was created was the GPA calculator. GPA calculator is used to determine your semester grade. The user inputs their class units and selects a letter grade from the drop down menus coded as JComboBoxes. After the appropriate selections have been made, the user can then select “Calculate GPA”. This will in turn, run a validation check within the UI, ensuring that the input is able to be calculated. If it is, the class will take in the value for the credit amount and convert the selection made in the JComboBox to a number value. Afterwards, the GPA Calculator will run a simple algorithm to compute the user’s semester GPA. The validation checks to see if a letter was placed into the credits field and if this is the case, the output will not display, since it is not able to be calculated. Pressing clear will reset the page to its default text fields and pressing return will take you back to the student tools page, by disposing of the current frame and creating a new one.

.

The final student tool that was created was the Grade Estimator. Grade Estimator can be used for any University, college, or even high-school class by inputting one’s current grades and their respective weights along with their desired grade ( inputted as a letter ) - in order to calculate their grade in the class and the grade they would need to receive on future assignments to reach their desired grade. Within the class, simple math is implemented in order to do the calculations. Instructions are provided, regarding on how to use the program. If the user enters an invalid string or number to any text field, there will be no displayed output. By pressing clear, all of the text fields will reset to their default value and pressing return will take you back to the Student tools menu. See the picture on the following page for an example.

Now that we’ve covered the Student Tools in more detail, let’s discuss the creation of an account or logging with an existing one and how the front end plays a massive role in aiding this process

The LoginGUI displays the default page of the application, providing two choices: log in or sign up. If incorrect credentials or nothing is placed in the respective text fields and the user initiates the login process, an error will appear on screen. In order to verify if the password is correct, the GUI calls upon the ReadFile method, which will retrieve information from the file and populate the school object. Furthermore, the class will call upon the methods from the Password class, taking in the string that was entered in the text field and checking whether or not the one from the file and the one entered are the same. Both passwords, both from the file and the one entered, are encrypted for security purposes. If they are the same, the user will be granted access to their to the main menu page.

The DisplayMatchesGUI will display a page with a list of the possible student roommates where you can pick a unique student and review their information. The list of names are obtained when getMatches is called. Inside of this method, ReadFile is called, which processes all of the students that are currently existing within that particular file, creating arraylists for them. After that is completed, an ‘internal counter’ of sorts will count the number of similar attributes you have with each and every student. Afterwards, it will utilize insertion sort and sort this list as a queue in descending order (from the student with most common traits to the one with the least). This provides the user with potential roommates, ordered from the best to the worst fit. These are presented in the UI as a dynamically built JList. See below for an example. When the user clicks on “get Information” with a person’s name highlighted, a pop up window will display the StudentMatch page where you can view their profile. The frame will display all the information about the selected person from the arraylist that contains the information that has previously been read from the account information file. “No preferences” can appear several times, denoting that the person you are looking at did not answer the question at the time of profile creating. If the user were to press ”get Information” without having a name highlighted, a pop up error would appear, telling the user what they need to do. Pressing return on the StudentMatch page will close the window and allow the user to keep viewing candidates.

Account creation is a very simple process that was the first milestone in the linking together of the “front end” and “back end”. The PasswordSetUpGUI is the first step for creating a new account. All three text fields require an input and failure to do so would result in a error message. Two passwords fields were added in order to make sure the passwords were the same per the usual standard. If they are not the same, an error message will appear notifying the user. Once user presses next, the name is added to an arraylist and written to a file, whereas the password is modified through the several methods from Password and HuffmanTree in order to get a unique code(binary to ASCII). The unique code is then added to the arraylist and written to a file for future login simplicity. See below for an example.

The StudentInfoGUI is the page right after the PasswordSetupGUI, where the program asks the user to identify which school they go. For now, we have only implemented an option for SJSU, but more schools can be easily added in the future. JComboBoxes were used for simplicity. The Student ID field takes in only numbers. If the user enters in letters or leaves it blank and and attempts to click “next”, the page will display an error and refuse to move to the next frame. This is done through simple regular expressions. The choices made on this page will be saved into an arraylist and copied to a file for future usage.

The PersonalInfoGUI will ask the user for more input in order to simplify the search and provide other users with more information about a potential roommate. The user can enter whichever questions they choose. If they were to not fill in a major, the program would assume they are “Undeclared”. Furthermore, if a JRadioButton has no selection made, the class methods will assign a default choice for them, specifically “No preference”. Otherwise, it will return the string representation of the selected respective JRadioButton and JComboBox. After the next button is pushed, all of the choices will be processed and written to a file for future searching. Below is an example of the PersonalInfoGUI.

Finally, the RoomPreferencesGUI helps to expand the list of student’s preferences and make the returned results of the StudentMatches more accurate. Similar to the PersonalInfoGUI, this program will ask new questions regarding to room preferences. If the user doesn’t pick an option, represented by JRadioButtons, then the choice for that question will be set to a default answer “No preference”. Each Radio Button corresponds to a string in the class’ methods, allowing an easy return process. The returned string will be placed into an arraylist and that arraylist will be once again copied over to a file for future searching.

Conclusion

This project involved a lot of teamwork with a non-strict division of labor between Matt (back-end), Raymond and William (front-end), and Raymond, William, and Khoi who worked on the Student Tools. We learned a great deal about the practical uses of data structures and algorithms. as well as adding extra features such as a user interface and a password (really, a checksum) implementation. We used many data structures from this semester, easily including arrays, ArrayLists, LinkedLists, Stacks, Queues, Maps, a custom data structure “Group,” Trees (the Huffman tree in particular), and more. Algorithms included are as follows: selection sort, merge sort (courtesy of the Java library), binary-to-decimal conversion, and Dijkstra's algorithm. We have striven to make this project unique by including some extra data structures and algorithms, as well as providing a UI, and we hope ideally to continue development on this project. On another particularly interesting point, we became familiar with character (ASCII) manipulation, as well as switch statements (a common command in C-style languages). As a group, we learned the difficulty and complications of working as a team on a single software project. One of our biggest challenges was merging our code; however, we were able to help each other, sometimes unexpectedly, and pull through to complete the project. We are satisfied with the state of our product, although there is much more room for future development.