A CLI Project With JCEV Using IDPM

Acronyms galore!  After learning about various software development tools and practices throughout this semester, I finally had a chance to apply them to a real group project.  This project involved creating a command line interface (CLI) which can be used to perform specific queries on the WattDepot server collecting data from the Hale Aloha residence towers.  We did this project in groups of three and used Issue Driven Project Management (IDPM) to keep the work flow moving smoothly.  Here I shall describe the process my group used and the resulting hale-aloha-cli-jcev system.

What is IDPM
First off, what is this issue driven project management?  Issue driven project management works by holding meetings often (every couple of days) to divide the current tasks into small work units that would take a day or two to complete.  These work units are called issues and are distributed between the group members.  The main principle behind IDPM is to consistently make, work on, and complete these issues so that every member knows what to work on and what to do next.  This keeps the flow of work consistent and helps to keep the project moving ahead smoothly and efficiently.  We implemented this methodology using the Google Project Hosting website which conveniently has an "Issues" page where we could manage our tasks.  We made rather extensive use of this page and ended up making more than 40 issues throughout the course of the project which aided us in getting everything done in a timely fashion.

Our project's issues page near the end of the project.

The CLI
So how does the project itself work?  The system itself is comprised of three main components.  The first is the main control class which runs the command line interface and grabs the user's input.  The second is a processor class which takes the user's input and tries to invoke the command that the user wants to run.  The third and final part contains the various commands that the user can invoke.  The main idea behind this approach is that each component is self contained and can treat each of the other components as a "black-box" as long as the developer knows what will be passed to the component he is working on.  For example, someone implementing an new command does not really need to know how the control class or the processor works as long as he understands that he should implement the provided Command interface and knows what will be passed to his command as explained in the interface documentation.  This makes the system somewhat modular to make it easy for developers to add to it.  The current release version implements all of the expected functionality and includes a total of six working commands: help (return a list of commands), quit (exit the CLI), current-power (returns the current power usage of given tower/lounge in kW), daily-energy (returns energy used by the given tower/lounge on given date), energy-since (returns energy used by given tower/lounge from given date to now), and rank-towers (rank towers from least to most energy used on given interval of days).

However, there are a couple quirks.  One major quirk is the quit command which needs communicating with the control class to stop the application.  This is a special case which required the quit command to throw a special exception which would be passed up to the control class as the obvious solution of using System.exit is a bad practice.  This works, but it does not quite fit the intent behind the design as both the control and the processor classes had to be modified to make it work.  Another quirk is the fact that the table generated in the processor class has to be modified to add a new command.  Ideally, the user could just add a new class and the processor could dynamically find it and add it, but we did not have time to implement a reflection-based processor class and resorted to using a hard-coded table.  As a result, anyone adding a new command would need to change the table in the processor class by adding a new put call to the table generation function.

Working with JCEV
As with any group project, you need a group and I had the pleasure of working with Jordan Takayama and Eldon Visitacion in team JCEV.  While it took us a little bit to adjust to each other's coding styles, we easily created a functional system before the due date.  This gave us time to check over each other's code and fix minor errors and inconsistencies like using "kWh" versus "kilowatt-hours".  Everyone also made a JUnit test case for each class with good coverage to ensure that everything is working properly.  As a result, I believe that our system contains quality software that has been thoroughly tested.

Conclusion
Overall, I believe team JCEV effectively used IDPM to create a CLI system.  We made good use out of IDPM to distribute and track the work that needed to be done which allowed us to finish with enough time to perform extensive checks and fix the tiny, non-system breaking errors.  Consequently, I believe that hale-aloha-cli-jcev is a quality software system that has been well tested to ensure that it works.  Not only that, but I have also gained valuable experience by putting all of the software engineering practices to use in an actual group project.  I have learned a lot from this project and I am definitely looking forward to next time!