Enhancing the BackR

In my last posts, I had covered some concepts about Issue Project Management and WattDepot. While in my last project with two fellow classmates we created a Wattdepot system called Hale-Aloha-cli-Bking, now it was our turn to enhance, not our system, but another system created by a different group.
That group is the "BackR", which I had previously made a technical review about its system. Just to mention the quality of the "BackR" system, I would say it looks quite comprehensive but at the same time very tedious to understand since it uses a wide range of advance functionality (such as Reflection). I had a hard time trying to figure out the overall functionality, since it is more complex than I thought. However, after going through all the code (which took me around an 1 hour), it was pretty simple to implement the three modules, described as follow:


(1)  set-baseline [tower | lounge] [date]

This command defines [date] as the "baseline" day for [tower | lounge].  [date] is an optional argument in YYYY-MM-DD format and defaults to yesterday.  When this command is executed, the system should obtain and save the amount of energy used during each of the 24 hours of that day for the given tower or lounge.  These 24 values define the baseline power for that tower or lounge for that one hour time interval.  For example, if lounge Ilima-A used 100 kWh of energy during the hour 6am-7am, then the baseline power during the interval 6am - 7am for Ilima-A is 100 kW.
-------------------------------------------------------------------------------------------------------------
(2) monitor-power [tower | lounge] [interval]

This command prints out a timestamp and the current power for [tower | lounge] every [interval] seconds.  [interval] is an optional integer greater than 0 and defaults to 10 seconds. Entering any character (such as a carriage return) stops this monitoring process and returns the user to the command loop.
-------------------------------------------------------------------------------------------------------------
(3) monitor-goal [tower | lounge] goal interval

This command prints out a timestamp, the current power being consumed by the [tower | lounge], and whether or not the lounge is meeting its power conservation goal.   [goal] is an integer between 1 and 99.  It defines the percentage reduction from the baseline for this [tower | lounge] at this point in time.  [interval] is an integer greater than 0.

For example, assume the user has previously defined the baseline power for  Ilima-A as 100 kW for the time interval between 6am and 7am, and the current time is 6:30am.   If the goal is set as 5, then Ilima-A's current power must be 5% less than its baseline in order to make the goal.  At the current time, that means that Ilima-A should be using less than 95 kW of power in order to make its goal.
-------------------------------------------------------------------------------------------------------------

After doing a preview of the three modules with my group, we thought it would be simple to implement all those three modules. Yes, it would be simple to enhance in our system, but not in a another group's one. However, having successfully passed the Three Prime Directives (reviewed in my last post), we had a well-code written developer guide for us to enhance the system.

As mentioned by my fellow classmate Sean Chung in his post, he explained how the system strictly enforce the use of a specific number of arguments,  giving us no choice for optional arguments. Sean fixed that, but I ran into another problem. How do we then keep the baseline for each tower after we call the method "set-baseline"? I couldn't save it in the Processor class since every time a user enter a new command, then it would create a new Processor object. I couldn't save it also in the MonitorGoal class, since an instance of every module is created after each command call. So I decided to save in the Main HaleAloha program. I had to use some static fields and methods; otherwise it will have the same problem as mentioned above since I would have to create a new instance of the main class after every "monitor-goal" command call.

It would be great that the previous group would have implemented a database to save the baseline, but I do not really blame them. It was an unexpected issue I had to deal with, in which most of the programmers out there usually experience. Therefore, this debugging experience taught me that how important is to implement something that will be useful to enhance and maintenance the system in the future. Also it taught me how important is to stick to the Three Prime Directives for the best functionality of the software.