About Me

My name is Lauren Gaber, and I attend the University of Michigan Dearborn. I am a sophomore majoring in computer science in the Computer Information and Science Department, planning to graduate around 2017. You can reach me at lgaber@umich.edu.



About my Mentors

My main mentor is Professor Bruce Elenbogen, who works in the CIS Department at the University of Michigan Dearborn. His areas of research include fractals, computer aided design, dynamical systems, algorithms and computer science education. He is currently working on papers concerning pairing systems, plagiarism detection of software systems and virus propagation. You can view his website at http://www-personal.engin.umd.umich.edu/~boss/.

My secondary mentor is John Baugh, a professor at Oakland Community College in the CIS Department working on his PhD in Computer Science. Baugh is a former student of Elenbogen's, and has experience publishing websites and designing research projects. You can view his website at http://profjpbaugh.com/.

Lastly, Kyle Shafer is another student at the university who is also working on this project. He is a part of Access Computing and signed up for DREU. I will be outlining the tasks for the project that were assigned to me and that I performed; if anything has been left out, it is probably about his side of the work for the project. You can reach him at kylers@mac.com. His website for DREU is http://www-personal.umd.umich.edu/~kylers/.



Research Project Outline and Goals

The main goal of the project was to convert the auto grader program that Professor Elenbogen previously wrote in Unix to Windows, and then use the software to perform a research project and provide a service to professors and their students. The conversion started from scratch; he told us what he did in Unix, and then we made it happen in Windows utilizing C# in Microsoft visual studio 2012 and its web forms to construct classes and a website that would use the classes to perform the auto-grading tasks. We named the auto grader CaseSense, because the grading is conducted by performing test cases on a student-submitted program. The software has three main parts: the user interface (website), data storage (database class), and the compiling, running, and scoring of programs (file class).

The website is where the students and professors upload their files to be used in grading. The professor uploads a test, optional hint, and answer for every test case for a project in a class they have created. The student uploads their source code (written in C++, C#, or Java) to be run for a project (using the file class) with the test cases as input and the output stored in a file and checked against the answers. A grading response is generated and displayed for the students, and their scores will be stored in the data table (with the database class).



Above: Original research outline submitted by Professor Elenbogen for approval of this project.



Weekly Work Journal

Week 5/5/14

Started working on exploring C# and web forms. Performed tutorials, kept track of hours. The jobs assigned were:

1.      Connect to the UMD-VPN and the computer the project is being hosted on

2.      Learn how to run and compile programs from the command line

3.      Look for a C# book if you need one.

All the goals were completed.


Week 5/12/14

Started working with the command line and C# more; started working in a console application file, and looking up how to interact with files through C# code. The jobs assigned were:

1.      Figure out how to make a command line system call in C#. Test: write an executable C++ file to compile and run.

2.      Build command line executable out of strings; also work on strings and concatenations and functions.

3.      If time, figure out if the diff statement can be used in windows or write a diff function for us to use on the project.

All the goals were eventually reached except #3, because I eventually ended up writing my own diff function in C#, and it was easier to manage what would make the professor answer and student output equivalent. Also, there was a bit of difficulty tracking down how to get commands to the command line; first it was with batch files, called with System.Dagnostics.Process; then it was managed eventually so the lines could be sent individually (and customized), so the hassle with changing the batch file over and over again was eliminated. I also started moving away from books and more to online resources for help.


Week 5/19/14

This week was mostly spent cleaning up work from last week, setting up affairs for getting paid and turning in the right forms for DREU and Access Computing.


Week 5/26/14

This week was the first meeting with John Baugh (meetings weekly). He has been coming to one every month. Usually he isn't needed as much as Elenbogen. There was more form work, some searching about what to do with the cl.exe compiler (which is still causing trouble) and setting up the other language's compilers (C# and Java; the main focus thus far had been on C++). The jobs assigned were:

1.      Change how you do the command stuff (do more stuff with cl.exe)(still trying to get cl.exe to work)

2.      Make class stuff to standard and be able to be called/used by Kyle

3.      Share class and file stuff with Kyle

4.      Find out if remote desktop files can be accessed between your logon user and Kyle's and the administrator (no; so we changed where it was).


Week 6/2/14

Kyle works on writing website, I work on more ways to make my class usable by it.


Week 6/9/14

The jobs assigned were:

1.      Research processes and threads. Discussion of thread writing had started, in order to be able to terminate the programs of the students that had a test case result of an infinite loop.

2.      Try to get the g++ command working in-code, minus the batch file (a struggle for a while but I managed to get it done this week finally, and do this for the other two languages. Cl.exe (visual studio compiler) had been temporarily abandoned once the C++ compiler from MinGW (g++) was working).

3.      Send update e-mail about meeting to Kyle (he was absent).


Week 6/16/14

Threads turned out to not be done in C# code, but on the command line with task kills, which was eventually figured out. There was also some figuring out of how to redirect standard error to a file, so students can see the compiler errors their program caused the auto-grader. There were struggles with killing the process, and it ended up that the task of killing the program run for a test case had to be done one at a time for every single test case, which lengthened the amount of time the processing took by a bit. This is something I hope to revisit and figure out how to fix.


Week 6/23/14

The next meeting was scheduled on 7/9/14, after the fourth of July. The data tables are being programmed in Access, and interact with my class by my class using its own class. The jobs assigned were:

1.      Brief discussion of unit testing - they #include the library in the main; so when you compile their file, you have to compile both the library file and the main file. (They are supposed to have the same name.) (This topic is still a little fuzzy, and actually is a bigger deal then it sounded this week).NOTE: (if this is ever the case, Schafer's code will have to upload the library file too... and I will have to know how to deal with it. Figure out how to write one yourself first.) (Not done yet)

2.      Data table interfacing start, with student and professor side programmed in Access. (completed 7/23/14)

3.      Logo due by next meeting. CaseSense is the name. Brief case image appreciated. (finished)




Above: CaseSense logo, designed by Marjorie Gaber.



Week 6/30/14

Worked on completing jobs from the last week, and updated my file class for a different computer directory structure. Worked on the website for a while, then stopped and went back to the job of writing and planning the database class.


Week 7/7/14

More database work; the website was being tidied up some.


Week 7/14/14

Some stagnation of the project; prioritization of getting things done:

1.      Fix problem student found by converting all g++ compiler use to cl.exe compiler use. Use batch files for testing (Not done, still struggling with it).

2.      Finish database class (finish writing all methods (may need to add a few more that aren't there yet) and qualifiers and delete what doesn't need to be there and clean up and document and cite.)


Week 7/21/14

Finished database class and assisted Kyle in writing a few calls to it to use in his website; these were for future reference when hooking up the rest of the website to the database. Finding other ways to get what we want for the cl.exe compiler in some other way.


Week 7/28/14

Worked on this website, figured out how to make the C++11 compiler work for g++; cl.exe abandoned until further notice for g++.

1.      Finish first draft of DREU website.

2.      Figure out how to get the C++11 compiler to work and install it in the file class.


Week 8/4/14

Finished work on C++11 compiler usage, started working on an additional way of program submission where the professor writes a driver and the students submit classes that the driver uses to produce output for the grader. This new type of submission had to be processed for all three languages like the first process was. We also started discussing the writing of instruction manuals for future programmers and users.

1.      Figure out how to test and write the new submission type into your file class.

2.      Ask John Baugh for instructions to add for help manual for programmers once you have the standards set

3.      Work on the programmer's manual.

Week 8/11/14

Clean up week for code, finished class submission task, worked on the instruction manual for programmers.

1.      Clean up code and comments and pre and post conditions, install updates to the program.

2.      Work on instruction manual for programmers


Week 8/18/14

Finished instruction manual for programmers and started filling out exit paperwork. Stagnation with the project website.



CaseSense Final Report