Modification of Hale-Aloha-CLI-TNT

Remember the Hale-Aloha-cli project from a few weeks ago? (if not, you can read about it in the earlier blogs). Well, for this part of the project our group (hale-aloha-cli-tiger) swapped codes with the hale-aloha-cli-tnt group in an attempt to modify and enhance each other's projects.

From the start, it took our group some time to even get started. The other group's code used reflection to link their command modules to the command processor while ours was simply hard coded. Because of this it took us a little while to figure out how reflection worked and how it processed the classes. Once we got and idea of how reflection worked, it was time to get started. 

Because of reflection, not changes had to be made to the group's command processor. The only thing we had to follow was their defined interface and how the processor processed the commands and their arguments. There were three commands we had to add to the existing code and because there was three people in our group, each of us were responsible for working on a single command each. The three additional commands were:

• set-baseline [tower | lounge] [date]
• This command defines [date] as a baseline for [tower | loung] and gets the power value for each of the 24 hours for [date]. Additionally [date] is an optional parameter and defaults to yesterday if not given.
• monitor-power [tower | lounge] [goal] [interval]
• This command prints out a timestamp and the current power for [tower | lounge] every [interval] seconds. Additionally [interval] is an optional parameter and defaults to 10 seconds if not given. The command is terminated by pressing any key on the keyboard.
• monitor-goal [tower | lounge] [goal] [interval]
• This command prints a timestamp and current power being consumed by [tower | lounge], and whether it is meeting its power conservation goal. [goal] is an integer between 1 and 99 and defines the percentage reduction from the baseline for this [tower | lounge]. This command also will not work unless the set-baseline command was previously called.

For this modification, I was responsible for the set-baseline [tower | lounge] [date] command. This command was very similar to some of the commands from the first part of this project and a lot of lines of code were reused. I had difficulty with the timestamps at first and the code kept returning 0.0 kWh. After a few hours of debugging and asking group members for help, I was able to get the command working fairly quickly and have be accessible to the monitor-goal command. Overall, the quality of my personal additional command is okay compared to the other commands implemented. I was overall more impressed by the reflection used in the command processor.

As a group we were able to complete all the additional tasks. The only problem we ran into was stopping the monitor-power command using any key. We were able to get it to stop while using the return/enter key, but not when any other key is pressed. The command, however, still prints out the required information. As for the other two additional commands, we were able to get them fully functional based on our understanding of the requirements.

In terms of the Three Prime Directives of Software Engineering: 

• Does the system accomplish a task?
• Can an external user successfully install and use the system?
• Can an external developer successfully understand and enhance the system?

The hale-aloha-cli-tnt application fulfills them all excellently. The system does indeed accomplish the task of querying the WattDepot server and returning various forms of data. An external user (in this case our group) was easily able to install and get the project working on our local systems. External developers (our group) was able to successfully understand and enhance the system. Even though we were not able to meet all of the requirements for the additional commands, we were able to add a semi-working command to the application.

Taking over a preexisting code is a pretty rough task. If the original code is unstructured, contains few comments, and/or is hard to read, modifying it becomes very difficult as a lot of time is spent trying to figure out how the code works. Our group was lucky enough to enhance code that was structured extremely well and provided a very strong base for additional modifications. I learned a lot from taking over this project and will use this experience in the future to make sure that any code I work out either alone or in a group is made as simple as possible so that an external developer can simply make modifications.