T2 : Energy Monitor
From SoftwarePractice.org
Team members:
- Anthony Donohoe
- Aaron Lim
- Daniel Nolan
Introduction
We are at a point in time where we must seriously consider the environmental future of our planet. Non-renewable resources are rapidly running out and must be rationed and preserved until renewable resources are implemented and fully independent and reliable. Our aim is to provide software for a measuring device that enables the user to fully understand how much energy they are using and use that information to help them reduce their energy usage.
This product will display voltage, current, line frequency, power, cost and CO2 emissions of the measured appliance.
Stakeholders
Product users
The product users will be using this device to accurately measure the electricity usage. The device will provide them with real time data. This device will allow them to better take control of their level of power consumption.
Energy Suppliers
This device may help reduce the overall load on the power grid. It would achieve this by encouraging smart power usage (minimizing expenditure or not using wasteful devices). This reduction in load will lead to less expenditure on behalf of the energy companies in regards to upgrading maximum grid capacity.
Retail Stores
Retail store will need a device that demanded by the public in order for selling the device to be a profitable venture. By designing an intelligent and easy to use device, there will be a positive outcome for retail stores.
Manufacturer of hardware
By designing and producing software that is easy to use and powerful that works effectively with the hardware, the manufacturer can guarantee that their large investment into the production of the device will reap rewards.
Software contracting company
The company needs to contract out good software engineers to be able to design and write the software for the device. The software created has to be efficienty and effectively designed in order to minimise bugs and unplanned expenditure and reduce the need for future software updates.
Government
As the Australian Government technically owns the power transferral infrastructure, it is in their best interests to reduce the load on the infrastructure, so that outages and failures in service levels are less likely to occur.
Future Generations
By utilising this device individuals would be able to make a conscious decision about their impact on what resources are available for generations of the future. By being environmentally conscious as well as efficiently managing their energy consumption, individuals can greatly impact upon the standard of life that will be experienced by generations to come.
Specifications
These are the Specifications as Per the Assignment Guidelines
- GUI Must allow Viewing of Chronological and Real-Time Data
- Must Calculate Electricity Expenses (Day, Week, Month, Year)
- Must Display Volts, Amps and Wattage to 0.2% Accuracy
- Must save to a unique record for multiple appliances
Miniature Unified Process
Inception
- Formed team (Aaron, Anthony and Daniel)
- Decided to do Energy Monitor as a project
- Established Ground Rules
- Identify Stakeholders
Deliverables
- Create Wiki
- Design notes
Elaboration
- Key use cases
- Use case diagrams
- Scenarios
- Sketch user interface
- Initial class and Sequence diagrams
- Key risks
Deliverables
- Work on Wiki
- Elaborate design notes
Construction
- Complete the design
- Revise use cases
- Write the code
- Create test cases
- Design system tests
Deliverables
- Finish Wiki
- Complete workbook
Transition
- Fix bugs in program
- Finish user interface
- Prepare documentation and deliverables
- Finalise Wiki and workbook
Deliverables
- CD with code
- Project documentation
- Workbook
Usage Scenarios
Scenario 1
Alexei receives a large electricity bill and is trying to figure out what devices in his house are taking up the most power. Alexei will use this device by plugging each appliance into the device and measuring the power consumption of each appliance. The device will store the data of each appliance and she will be able to go back after all the logging and compare each device to find out which device is consuming the most power and hence adding to her large electricity bill.
Scenario 2
Melissa is a High School Student working on a project where she has to measure the power output of different devices in her house and compare them to the output of other students. Melissa will choose her devices and pug them into the measuring device. She will then be able to retrieve all the stored data of the different appliances once they all have been measured. She will then print off these results and take them to school where she will compare her results with her classmates.
Scenario 3
John-Paul is studying Resource Economics and he wants to find out his carbon footprint based on the electricity used by devices in his home. By plugging the appliances that he wants into the device, he can get a CO2 reading of how much Co2 emissions each appliance gives off in a specific time frame.
Scenario 4
Roger is looking to buy a new fridge and wants to compare the electricity usage of his friends fridges so that he can get one that uses the least electricity. Roger will take the device to each of his friends' place and measure the power consumption of each fridge. When he is done he will compare the power consumption of each fridge and choose to buy the fridge that has the lowest power consumption.
Use Case Diagrams
The Consumer is the person that is going to use the device to measure the power consumption of appliances.
The External user is a person who analyses the data stored on the device and does not measure anything.
Essential use cases
| User action | System responsibility |
|---|---|
| 1. Plug in device | |
| 2. Zero and monitor | |
| 3. Offer output choices | |
| 4. User makes choice | |
| 5. Log and display data | |
| 6. Logs data until user intervenes | |
| 7. User stops logging | |
| 8. Offer more choices (includes store data) | |
| 9. Return to step 4 or turn off |
| User action | System resposibility |
|---|---|
| 1. Plug in device | |
| 2. Zero and monitor | |
| 3. Offer output choices | |
| 4. User makes choice (Cost projection) | |
| 5. Update cost data from source | |
| 6. Display data and costing | |
| 7. Offers choices | |
| 8. Return to step 4 or turn off |
| User action | System responsibility |
|---|---|
| 1. Plug in device | |
| 2. Zero and monitor | |
| 3. Offer output choices | |
| 4. User makes choice (Cost projection) | |
| 5. Offer drop menu of different appliances | |
| 6. Select device or create new one | |
| 7. Log and save data until user intervenes | |
| 8. Change device and repeat step 1-7 | |
| 9. Offer comparison or further options | |
| 10. Make choice | |
| 11.Show data | |
| 12. Offer more choices | |
| 13. Make another choice or turn off device |
| User action | System responsibility |
|---|---|
| 1. Turn on device | |
| 2. Offer choices | |
| 3. Make choices with past logged data | |
| 4. Load and display data | |
| 5. Offer choices | |
| 6. Repeat step 3 or turn off |
CRC Cards
| Class Name: Input | |
|---|---|
| Responsibilities | Collaborations |
| 1. Take User Input 2. Provide User Input to Other Classes | 1. Calculator Class (Feeds data for calculations) 2. Manager Class (Gives Application name for Hash Table) |
| Class Name: Manager | |
|---|---|
| Responsibilities | Collaborations |
| 1. Takes Data from other Objects 2. Uses this data to create new instances of the Application Class 3. Adds this new instance to its' Hash table 4. Provides information about instances of Application to other Classes | 1. Appliance Class (Creates new instances of this Class with the property 'appName' 2.Input Class (Takes the data from this input to create new Appliances and add to its' Hash Table) 3. Menu Class (Responds to actions in menu to create new Appliances) |
| Class Name: Appliance | |
|---|---|
| Responsibilities | Collaborations |
| 1. Instance Created by Manager Class 2. Has name information for the Appliance it represents | 1. Manager Class (Reference to this object is stored in a hash table inside Manager Class) |
| Class Name: Menu | |
|---|---|
| Responsibilities | Collaborations |
| 1. Provides options for the user to create new Appliance, open old Appliance data or close the Program | 1. Manager Class (Input from the Menu creates new instances of Application via the Manager Class) 2. Manager Class (Using the Manager Class to open old files) 3. GUI Class (Tells the GUI the files to use for older data) |
| Class Name: Calc | |
|---|---|
| Responsibilities | Collaborations |
| 1. Takes input values from Manager or Input 2. Uses these Input values to Generate Voltage, Current, Power, Co2 and Cost values. 3. Generates arrays with these values to update the GUI class' tables | 1. Net Class (Gets the current provider rates from Net class so that it can calculate costs) 2. Input Class (Takes values from input class in order to provide real-time power, etc. values) 3. GUI Class (Creates Arrays of data that are parsed into elements in the GUI in order to provide the real-time and time-shifted data) |
| Class Name: Net | |
|---|---|
| Responsibilities | Collaborations |
| 1. Holds current provider cost values 2. Can update these values from an XML file on the internet | 1. Calc Class (Provides the Calc class with the latest values inside the object when requested) |
GUI
Initial Designs
These initial designs are scanned from my workbook(Daniel Nolan) and are the first sketches for the User Interface that were deemed appropriate.
Development
As can be seen by the sketching mockups and the final output Mockup (Required due to a problem with DefaultTableModel in Java), very little needed to be changed as the layout worked quite effectively and presented all of the information required to meet the specifications.
Final Output Mockup
Updated Intended OS X GUI
(Main App Window)
Updated Intended OS X GUI
(Add New Appliance Window)
Initial Class Diagram
Description of Initial Diagram
This is the initial class diagram and the first UML diagram of the program using our design methods and concepts.
It outlines a clean and very Object Oriented system whose features Include:
- Two differently defined input systems for two different types of input
- Full output of both past data and real-time data
- Cost generation for several sources for the times specified
- An Application HashMap allowing for easy sharing of application data throughout the program
- A GUI system that uses updated data arrays to refresh tables and modify their contents.
Final Class Diagram
Description of Final Class Diagram
This is the NetBeans generated complete Class Diagram of our final project output. As is plainly obvious it is markedly different from our initial conception due to, predominantly a lack of communication between all parties, and issues with time management. The marked change is covered in more depth in the Reflections/Outcomes section (Insert Link)
What can be seen from the above diagram is that we have a working system that undertakes all of the System Test cases and has the following features:
- An array updating Table system to refresh tables on the main GUI
- A perfectly working DataIO class that allows Voltage, Current, Frequency, Power and Co2 all to be both saved and read from bytestream files
- A costs projection array that not only projects costs for the periods of time, but also for a multitude of providers
- A real-time data generation and output system.
- It also generates approximate Carbon emissions for the particular appliance based on the power levels of the appliance.
Use case collaboration diagrams
User wants to display data for appliance
User wishes to add a new device
Calculating pricing operation
Use case Sequence diagrams
Displaying Data
This diagram shows the process for the task of displaying past data from a data file onto the GUI. The Data file is chosen by the Actor in the situation, it is then parsed through the ReadData Class and an array is created from the past data, this array is then used to create a JTable on the GUI with that data.
Adding new Appliances
This diagram shows the process for adding a new appliance and assigning input data to it and saving it to file. The Actor chooses to create a new appliance, the data for this appliance (The time and the name of the appliance) is passed to a new instance of the appliance class. This class then generates the data for that particular time interval and stores that data into a bytestream file in the C: drive of the computer, under the name that the actor gave to the appliance.
Displaying Cost Projections
This diagram shows the process for displaying cost projections onto the GUI from a saved data file. Data from a past output is chosen and passed through to the ReadData Class that generates cost values based on the data that is passed to it. The cost values are stored in an array that is sent to the GUI, generating the table with the different cost values
Unit Test Cases
These tables just indicate the expected output of the methods of those Classes key to the program. These tables allowed us to perform accurate JUnit testing as we had expected Pre Conditions and expected output values, making it easy to discover anomalies and bugs in our code.
Input
| Method | Pre Condition | Post Condition |
|---|---|---|
| rVoltage | Random.nextDouble | returns v skewed by a random proportion |
| rCurrent | Random.nextDouble | returns i skewed by a random proportion |
| rFrequency | Random.nextDouble | returns f skewed by a random proportion |
| getFrequency | freq | returns frequency |
| getPower | power | returns power |
| getCurrent | current | returns current |
| getVoltage | voltage | returns voltage |
| setFrequency():double | null | Sets the frequency to the double value |
| setCurrent():double | null | Sets the current to the double value |
| setVoltage():double | null | Sets the voltage to the double value |
ReadData
| Method | Pre Condition | Post Condition |
|---|---|---|
| dataRead() | null | Reads data Selected |
| getReadStatus() | false | If data has been read returns true |
| getVoltage():int | voltage array | Returns i array value |
| getCurrent():int | current array | Returns i array value |
| getFrequency():int | frequency array | Returns i array value |
| getPower():int | power array | Returns i array value |
| getCost():int | cost array | Returns i array value |
| getCo2():int | co2 array | Returns i array value |
| avVoltage() | voltage array | Returns average of array |
| avFrequency() | frequency array | Returns average of array |
| avCurrent() | current array | Returns average of array |
| avPower() | power array | Returns average of array |
| avCost() | cost array | Returns average of array |
| avCO2() | co2 array | Returns average of array |
| createCostArray() | null | creates 2d array costPro |
| voltage() | current Voltage | returns voltage value |
| current() | current Current | returns current value |
| cost() | current Cost | returns cost value |
| power() | current Power | returns power value |
| frequency() | current Frequency | returns frequency value |
| co2() | current co2 | returns co2 value |
| getCostPro() | costPro array | returns the array |
| guiAverages() | null | Creates array with all averages |
| getInputArray() | null | Creates a 2d array with averages |
| getInputArray2() | null | Creates a 2d array with averages |
| getCostArray() | dataRead | Creates a 2d array with cost values |
Calculator
| Method | Pre Condition | Post Condition |
|---|---|---|
| calcPower:double,double | null | Calculates power (kw/h) from v * i |
| calcCost1:double,double | null | Calculates cost from power * rate |
| calcCost2:double,double | null | Calculates cost from power * rate |
| calcCost3:double,double | null | Calculates cost from power * rate |
| calcCost4:double,double | null | Calculates cost from power * rate |
| calcCo2:double | null | Calculates co2 from power * emissions Constant |
System Test Cases
Capture Power Values
| 1. Capturing Power Values from a Fridge | |
|---|---|
| User action | System responsibility |
| 1. Initialise Program | |
| 2. Display Open Menu | |
| 3. Choose to Add new Fridge | |
| 4. Creates new appliance file for fridge | |
| 5. Log and display Power Values | |
| 6. User stops logging and exits program | |
Display Power Values
| 2. Display stored Power Values from a Fridge | |
|---|---|
| User action | System responsibility |
| 1. Initialise Program | |
| 2. Display Open Menu | |
| 3. Locate and open fridge file | |
| 4. Reads Power Values from fridge file | |
| 5. Display fridge Power Values | |
| 6. When user is finished, user exits program | |
Save Data
| 3. Save Power Values from a Fridge to a File | |
|---|---|
| 1. Initialise Program | |
| 2. Display Open Menu | |
| 3. Choose to Add new fridge | |
| 4. Creates a new appliance file for fridge | |
| 5. Logs fridge Power Values | |
| 6. User exits program | |
| 7. System saves logged Power Values into data file | |
Display Cost Values
| 4. Displaying Cost values from stored Power Values | |
|---|---|
| User action | System responsibility |
| 1. Initialise Program | |
| 2. Display Open Menu | |
| 3. Choose to open existing Fridge Power Values | |
| 4. Opens and parses Fridge Power Values | |
| 5. Generates Cost Values for input Fridge Power Values | |
| 6. Display the generated Cost Values | |
| 7. When User is finished, User exists program | |
Usage of Software Development Infrastructure
Revision Control (SVN)
We used a free SVN service so that we could have greater control over how the application developed without breaking. SVN's revert abilities were useful in several instances where there were major differences between files. However, after that incident we used a rules based system in order to make sure that the code kept working.
- Do not Commit if the code does not compile
- Use locks appropriately
- Don't modify the code of other team members unless specifically addressing a problem or adding methods/variables that won't break that code
- Use the SVN commit Tickets to provide valuable information about the changes you have made (Unfortunately near the end this started to break down greatly)
Progress Management (Trac)
Trac Integrates with SVN Because Trac is such a fantastic HTML frontend to SVN and allows you to keep a full record of commit logs; we could better understand what we were working towards as a team. Using the commit logs and the ticket lists we could deal with individual bugs efficiently, even when at home.
The combination of both Trac and SVN allowed us to maximise the amount of time we spent building the project and to minimise the amount of time we spent fixing up the mistakes of other individuals.
Build Automation
When we were reaching the conclusion of putting our project together and needed to test the project completely (Before we realised the issues with GUI elements) we looked into using Ant inside the IDE. However, time restrictions limited the amount of time that we could spend researching Ant. Thanks to the information that we garnered during the research, we will be sure to use it in any future projects that require the same level of output and rigorous testing.
Conclusion
After completing the assignment our group has learnt some valuable lessons. We believe following the guidelines of the UML process more closely we could have produced a far more functional and far better designed program. With more preparation and organisation and a better management of time, we feel we would have had a fully functional program.
A wishlist, so to speak, of more functions we would have included with more time would have been:
- The ability to take more inputs and generate differing values over a larger time period
- Ability to manipulate (Grab averages over larger time intervals) and add to past data.
- The ability to output the data as a CSV or similar format, rather than just pure bytecode
- A real-time data window that updated the current appliance values each second
- A real-time graphing option that would allow graphing comparisons between different devices
- Ability to Calculate cost differential between different appliances
Positives
One positive experience that all of the members of the group took from the project was the increased reliance on their own information sourcing skills, as well as the increased confidence they have now as Java programmers. At the beginning of the project, all three of us had fairly rusty Java skills, despite our performances in OOP. However, through consistent effort and research, we all feel now that we have a far greater command of the concepts of OO and programming in Java in general.
Furthermore, now with the knowledge of the systems of Object Oriented Design, an understanding of UML and the processes undergone to generate a functional program that meets certain specifications, we feel we are far better placed to produce larger programming projects in the future. Considering all of our degrees rely heavily on programming knowledge as well as group programming work, this can only have a positive outcome.
Negatives
We feel it would not be remiss of us to say that we did not achieve at our potential. One of the initial problems was our lack of paying attention to the specifications for the device. None of our group members attempted to figure out exactly what it was the software was meant to achieve. This was just general indolence and mismanagement, however we did 'feel our way' somewhat to the outcomes required (Excusing some outputs). Also as can be clearly seen above there is a marked difference between our initial UML diagram for the project and our final project outcome. This is due entirely to lax behaviour on our parts. We did not manage our time or design effectively and had the final design split into backend and GUI with no indication of what particular values we would be producing, nor any indication as to what we would be using them for. We diverged from the UML and the OOD guidelines due to a lack of familiarity with the processes. The fact that we saw OOD as such an alien concept was due entirely to our lack of effort in taking advantage of the information that was given to us.
Future Development Use
We do feel, however, that this outcome places us in far better stead to utilise the tools and ideas that OOD supplies us with due to the realisation that we would have saved many days of wasted effort by simply organising our structure using the processes we'd been given and using UML to help us generate the majority of our program. We feel that after seeing the outcomes that UML (And the other OOD processes) can so efficiently generate, there is a significant level of embarassment on our part at our own apprehension to use those tools and the subsequent quality (or lack thereof) of our output.
References
Wu, T. 2001, An Introduction to Object-Oriented Programming with Java, 5th edn, McGraw Hill, New York.
----Used as a reference for implementing the code
Bennett, S. McRobb, S. Farmer, R. 2006, Object-Oriented Systems Analysis And Design -Using UML, 3rd edn, McGraw Hill, New York.
----Used as a reference for the UML models
Sun Microsystems, 2007, The Java Tutorials, Sun Microsystems, viewed May 2007, <http://java.sun.com/docs/books/tutorial/>
----Used as a reference for implementing the code
GUI Specific References
All were Accessed between 1st April - 30th April
Speed Up Swing Construction with Multiple JPanels, <http://www.javaworld.com/javaworld/jw-10-2002/jw-1004-dialog.html>
JTable and Large CSV files,
<http://forum.java.sun.com/thread.jspa?threadID=5138036&messageID=9506301>
Instructor comments
Use cases are good. What about usage scenarios? Lian 21st March
Post presentation session milestone: For stakeholders, elaborate on their needs/concerns. Usage scenarios - selection of users and their motivation is good, but need to describe specific use of the device in context, so include the information you talked about in the presentation! Use cases are fine. But on Use Case Diagram, why is Log Data floating? What is the actor, External User? Choice of classes is okay. Class diagram is very basic at this stage. Sequence diagrams are reasonable at this stage, but some are incomplete. Be careful with the notation, eg. do not show an Appliance object existing at top of diagram when it only appears at the point of creation later in time.
Lian 4th April