Team 7: Energy Monitor

From SoftwarePractice.org

This page details the documentation involved in Team 7's Energy Monitor System.

Contents 1 Project Introduction 2 Team Members 3 Scope 4 Key System Elements 5 Key Stakeholders 5.1 Business and Market 5.2 Development 5.3 Maintenance 5.4 System Administration and Deployment 5.5 End Users 6 Key Risks 7 Key System Requirements 8 Project Management Plan 9 Usage Scenarios 10 Essential Use Cases 10.1 Capture Data 10.2 Save Data 10.3 Load Data 10.4 Display Data 10.5 Get Help 11 Detailed Use Cases 12 Use Case Diagram 13 Initial Design Sketches 14 Final Design 15 User Guide 16 Brainstorming - Initial ideas for possible Classes 17 Final Classes 18 Class Responsibility Collaboration (CRC) Cards 19 Original Class Diagram 20 Initial Class Diagram 21 Class Diagram 22 Collaboration Diagrams 23 Sequence Diagrams 24 Design and Implementation 24.1 Discussion of our Design 24.2 Team Work 24.3 Coding 25 Contracts 25.1 Device Class 25.2 Collector Class 25.3 Calculations Class 25.4 Graphing Class 26 System Test Cases 26.1 Capture Data 26.2 Save Data 26.3 Load Data 26.4 Display Data 26.5 Get Help 27 Discussion and Concluding Remarks 28 Future Developments 29 References 29.1 General Research 29.2 Coding 29.3 Documentation 30 Instructor comments

Project Introduction

In recent years Australians have become more aware of the unsustainable rate of energy consumption within the home. With such a heavy technological reliance on electricity to provide heating, cooling, lighting, washing, cooking and entertainment, a need to monitor and assess the efficiency of common electrical appliances has been recognised. This 'energy monitor' is planned to take the form of a handheld device with the ability to interface to all kinds of household electrical devices, with future development to include hardwired equipment such as lighting.

The aim of this project is to develop a prototype of the software that would run on this device in order to simulate and demonstrate its functionality. As such, a number of the program's modules would eventually be replaced by real hardware and interfacing equipment.

Team Members

Simon Archer - 10460210

Matthew Hellyer - 10306328

Pulkit Saxena - 10460234

Scope

The scope of a project defines the limits of what is and what is not to be implemented (according to user requirements). The scope of this Energy Monitor system is listed as follows.

The system will:

• allow a user to manually enter electrical device data
• store a collection of devices (and their associated attributes)
• display current collection of devices
• perform calculations and draw graphs of selected data
• allow device data to be saved external to the program
• allow externally saved data to be loaded into program
• give detailed help to the end user as required

The system will not (at this stage of development):

• allow direct hardware interfacing between an electronic device and the proposed handheld energy monitor (since it does not exist yet)
• automatically compare different devices in terms of their attributes
• automatically link data of the same device captured at different times for comparison (these last two can be done manually by the user)

Key System Elements

The key elements of the Energy Monitor system are:

• a user friendly graphical user interface (GUI)
• a data randomiser to provide simulated values for calculation and graphing
• device data calculation and graphing functionality
• an easily understood user guide to assist end users in performing system functions
• device data saving and loading

Key Stakeholders

Business and Market

Our project's effectiveness will ultimately depend on how well it interacts and adapts with marketing solutions. Our design will be influenced by concerns such as cost, size, reliability, aesthetics, how innovative and new the product is, and its ability to be user friendly. Taking these factors into consideration will help provide these stakeholders with a great product that dominates the market.

Development

The development and stakeholders involved with directly influence our project. The amount of time and effort invested within the project will be directly evident in the complexity and quality of the final product; this will have to play a large role in the design of and construction of the product if it is to succeed above others. Outsourcing and referencing will also be a concern, as plagiarism and copyright laws need to be protected, while the allocation of tasks and teamwork organisation will also directly impact the direction and development of the project.

Maintenance

In the software industry, maintenance plays a vital role in any software life cycle. A product needs to be easily maintained, in order to meet the needs of future technological advances and interact within a ever expanding and growing technologically based society. Documentation should be easy to read and follow, well structured, and incorporate standards like UML. A project that is cost effective to maintain will have a large advantage over other products.

System Administration and Deployment

We envision that our product will be compatible with a variety of hardware solutions and be able to adapt to a variety of situations, rather than confining the software to a small hardware solution. To achieve this we will pursue a design that has strong foundations, where patches and firmware upgrades can become available.

End Users

End users are probably the most important stakeholders to consider as they are the target audience. The product needs to meet user’s expectations, providing a efficient and reliable environment. Help features, tutorials, and instructions extend the systems user friendliness which appeals to the vast majority of users. End users are also looking for reliable calculations, and a bug/error free environment. Considering these end users requirements and adapting the product to meet there needs will be the most important requirement feature.

Key Risks

Three key risks identified in terms of this project's development are:

1. Scope Creep - The tendency for a project to increase in scale and complexity during development resulting in a project that is unable to be completed within time, technical and financial constraints. The intention of the team is to identify and develop core functionality first, based on the given Key System Requirements.

2. Schedule Management - A common problem when managing a project are unexpected delays in development caused by an underestimation of the work involved, insufficient resources (financial, personnel or technical skills) or simply failures in delivery of required materials. Ensuring that sufficient time is allocated to allow for completion of each aspect of the design, implementation and testing of the project, as well as accounting for unanticipated delays, can be quite challenging. The team has developed a Project Management Plan, based on the Minature Unified Process (MUP), to give direction and focus to the team and to lower the risk of falling behind schedule. The schedule identifies the requirements and key system deliverables to be completed each week.

3. Reliability, Stability and Performance - The preceding two risks contribute substantially to the overall quality of the software system produced. If the project runs behind time or too many features are attempted, the end result is usually a poorly tested and poorly functioning piece of software. Meeting these non functional requirements, common to all types of projects, will in this case involve constructing well written unit test cases, based on the system use cases, that demonstrate good code coverage and adhere to precondition and postcondition constraints.

Key System Requirements

• Measures power consumption and energy usage

• Control the monitoring of energy usage

• Display chronological and real time data

• Displays power in kilowatt-hours (kWh)

• Calculates electrical expenses for a day, week, month or year

• Displays potential difference (in volts), electric current (in amperes) and power (in watts) with a 0.2% accuracy

• Monitors voltage, line frequency and power factor

• Records and stores data

Project Management Plan

This is the team's project management plan using the Minature Unified Process (MUP).

Usage Scenarios

1. 78 year old Mary is concerned about the amount of power she is consuming in her home. She has heard about energy saving devices that use "green power" and wants to compare her household electrical devices to them. She needs a system that is intuitive, easy to use and accurate, without being overly technical.

2. Joe wishes to compare the power factors of a number of electrical appliances to determine their relative efficiency. He needs a system that can store and compare this data, both to previously recorded data of the same device and that of other devices.

3. Adam wishes to measure the power consumption of a light bulb over the period of one month and calculate the total electrical expense incurred.

4. Kyle wants a graphical representation of the voltage, current and power functions of a specified electrical device for easy visual comparison. He needs a system able to clearly and accurately display these functions based on the data collected for each device.

Essential Use Cases

Capture Data

Before the program can process electrical device data, the program must be able to collect this data from a device. This is done either by the user specifying the data, or by capturing it directly from the connected device. Data that is collected by the program is then displayed for the user in the form of a table.

User Action	System Responsibility
1. Open program
2. Specify how you would like to input data
	3. Accept and manipulate input
	4. Show output in table

Save Data

Once device data has been successfully captured, the user needs to have the option to save the data to an external file.

User Action	System Responsibility
1. Choose to save data
	2. Save data to external file

Load Data

Instead of capturing data, a user can also load previously saved data into the current data table.

User Action	System Responsibility
1. Open program
2. Choose to load data
3. Select data file to load
	4. Retrieve data file
	5. Load data into data table

Display Data

Once the list of electrical appliances has been specified or loaded and exists in the data table, users need to be able to choose a device from the table and display related calculations and graphs of the data.

User Action	System Responsibility
1. Choose device from data table
	2. Retrieve record from data table
	3. Send device data to calculator
	4. Calculate data
	5. Send calculated data to grapher
	6. Display graphs and calculations
7. Update calculation input as desired
	8. Update graphs and calculations

Get Help

An important feature of this program is the ability to get help. Users are able to access a complete user manual, that gives a step by step instruction on how to execute each program operation, as well as view the email addresses of each of the designers of the program for direct troubleshooting support.

User Action	System Responsibility
1. Request help
	2. Load user manual
3. Request online support (optional)
	4. Display email addresses of designers

Detailed Use Cases

Use Case Diagram

The website http://www.agilemodeling.com/essays/useCaseReuse.htm was used to research the 'extends' and 'includes' stereotypes, but it was determined that these did not apply to any of the use cases in the Energy Monitor system, given how very different they are in functionality and purpose.

Initial Design Sketches

As noted in the usage scenarios, the design of the program should be such that it can be easily accessed and able to make calculations and display graphs near instantaneously. The team developed an initial GUI design sketch aimed to be user friendly and therefore better suited to the end user.

Main window in which the user can see Device data, calculations and graphs

Specify Input window in which the user is able to add data for a specific device

Final Design

Create Item - Identify the electrical appliances and their relative info.

User Guide

The User Guide contains directions on how to use the Energy Monitor system correctly, effectively and efficiently. Use the following link to download the file:

http://www.uploading.com/files/BK27PE68/EnergyMonitorUserGuide.doc.html

Brainstorming - Initial ideas for possible Classes

• Device Class
• Collector Class
• Calculations Class
• Data Recording Class
• Random Data Generator Class (Simulator Class)
• Graphing Class
• GUI Class
• Help Class
• Compare
• Monitoring

Final Classes

• Graphical User Interface (GUI) Control Class - manages the interface between the user and program including specified device input, saving and loading of device data files, help functionality, main data table, calculations and graphing display
• Device Class - template for all electrical devices
• Collector Class - an array of Device objects
• Calculations Class - handles all electrical calculations, such as the energy usage (in terms of total consumption (in kwh) and cost (in dollars)) of each device, device efficiency (in terms of power factor (as a percentage)) and waveform phase shifts (in radians)
• Graphing Class - takes electrical calculations and plots voltage, current and power waveforms on one set of axes for comparison.
• Table Class - allows the creation of the GUI table and all data access (reading and writing) to the table
• FileIO Class - handles the loading and saving of Device array data files
• ImagePanel Class - responsible for embedding the background image into the GUI

Class Responsibility Collaboration (CRC) Cards

Class Name: Graphical User Interface (GUI) Control Class
Responsibilities	Collaborations
1. Enter new device data 2. Store/save data 3. Restore/load data 4. Display device table 5. Display graphs 6. Display calculated data 7. View help features	1. Collector Class (add captured data as a Device object) 2. Graphing Class (displays graphs) 3. Calculations Class (display calculations) 4. Table Class (display Device data in a table) 5. FileIO Class (provides interface for saving and loading external data files 6. ImagePanel (loads GUI background image)

Class Name: Device Class
Responsibilities	Collaborations
1. Get device attributes 2. Create device instance	1. GUI Class (use captured data to create a Device object)

Class Name: Collector Class
Responsibilities	Collaborations
1. Store a collection of Device instances 2. Load Device instances from saved file 3. Save Device instance collection to file	1. Device Class (create an array of Device objects)

Class Name: Calculations Class
Responsibilities	Collaborations
1. Perform calculations on Device object attributes	1. Table Class (perform calculations on table data)

Class Name: Graphing Class
Responsibilities	Collaborations
1. Plot generated Device object attributes on a graph	1. Table Class (use table data for graphing) 2. Calculations Class (use calculations for graphing)

Class Name: Table Class
Responsibilities	Collaborations
1. Create data table for display on the GUI 2. Add data elements captured from the end user to table 3. Provide data for calculations and graphing 4. Provide data for saving to an external file and accept data when loading from an external file	1. Collector Class (add Device object array to data table)

Class Name: FileIO Class
Responsibilities	Collaborations
1. Save data table to external file 2. Load external data file into table	1. Table Class (save data from or load data to table)

Class Name: ImagePanel Class
Responsibilities	Collaborations
1. Load background image into GUI	(none)

Original Class Diagram

Initial Class Diagram

Class Diagram

Collaboration Diagrams

Sequence Diagrams

Design and Implementation

Discussion of our Design

Our project design is actually complicated despite our attempts to keep things simple. Our design utilises classes, methods and attributes which come together in an object oriented way. The design would have been considerably different if the program was written in another laguage such as Visual Basic or even C. Following the Miniature Unified Process we underwent an Inception, Elaboration, Construction and Transition stage as we sought to meet the requirements of the design brief, being careful to address issues like stakeholders and project scope.

Team Work

Working in a group and incorporating our team player skills, we were able to delegate tasks, share ideas and manage responsibities. It was hard to equally share the work load but where some team members lacked others stepped in to lend a hand. The greatest advantage of working in a team was not only having shared responsibility but also being able to brainstorm and troubleshoot together - three heads are better than one. Communication was the most important factor that influenced the group's effectiveness, relevant, regular and effective group meetings were essential.

Coding

Code implementation was probably the biggest challenge our group faced. Limited experience in the Java programming language led to hours of refreshing, research and programming practice before work was done on the program itself. However at the end of the project each member can say they have not only learnt the basics but feel confident in this programming language.

Contracts

The following contracts specify each class in terms of their methods and the pre- and post-condtions associated with them. This was useful in performing unit testing to ensure that the data sent to each method (via its arguement(s)) resulted in the correct data out.

Device Class

Method	Pre Condition	Post Condition
1. setType(): String	null	Sets value of Type string
2. setBrand(): String	null	Sets value of Brand string
3. setVoltage(): Double, Double	null	Sets value of Voltage double attribute
4. setVoltage(): Double, Double	null	Sets value of Voltage double attribute
5. setCurrent(): Double, Double	null	Sets value of Current double attribute
6. getCurrent():	amps	Returns attribute Current
7. getVoltage():	volts	Returns attribute Voltage
8. getType():	type	Returns attribute Type
9. getBrand():	brand	Returns attribute Brand

Collector Class

Method	Pre Condition	Post Condition
1. addElementArray(): Device	newDevice	Copies newDevice into testDevice array[]
2. countElementsInArray(): Integer	count = 0	Sets value of count to the location of the first null in the testDevice array[]
3. importElements():	count2 = 0, count = 0	Sets values of count and count2 and copies the element array into the testDevice array
4. getDevice(): Device[]	testDevice	Returns testDevice

Calculations Class

Method	Pre Condition	Post Condition
1. setPower(): Double, Double	getCurrent, getVoltage	sets value of Power double
2. setEnergy(): Double	null	sets value of Energy double
3. setkwh(): Double	getPower, getTime	sets value of kwh double
4. setElectricalExpense(): Double	getkwh, getRate	sets value of Electrical double
5. setTheta(): Double	Math.Random	sets value of Theta double
6. setPowerFactor(): Double	getTheta	sets value of PowerFactor double
7. getJPanel():	null	creates JPanel
8. getInput():	user Input value	returns Input value
9. getOutput():	computed output value	returns Output value
10. getPower():	computed power value	returns Power value
11. getEnergy():	computed energy value	returns Energy value
12. getkwh():	computed kw/h value	returns kwh value
13. getTheta():	computed theta value	returns Theta value
14. getPowerFactor():	compute power factor value	returns PowerFactor value

Graphing Class

Method	Pre Condition	Post Condition
1. plot():	null	Plots the three graphs
2. setBrand(): String	null	Sets value of Brand string
3. setVoltage(): Double, Double	null	Sets value of Voltage double attribute
4. setVoltage(): Double, Double	null	Sets value of Voltage double attribute
5. setCurrent(): Double, Double	null	Sets value of Current double attribute
6. getCurrent():	amps	Returns attribute Current
7. getVoltage():	volts	Returns attribute Voltage
8. getType():	type	Returns attribute Type
9. getBrand():	brand	Returns attribute Brand

System Test Cases

Capture Data

User Action	System Responsibility
1. Open Energy Monitor program
	2. Load Energy Monitor program
3. Go to File > Device Input
	4. Display 'Input' window
5. Select 'Specify Device Input' radio button
	6. Display 'Specify Input' window
7. Enter desired form field values
	8. Create new 'Device' object
	9. Load 'Device' object into GUI table

Save Data

User Action	System Responsibility
1. Go to File > Save
	2. Display 'Save' window
3. Specify file name
	2. Save data file

Load Data

User Action	System Responsibility
1. Open Energy Monitor program
	2. Load Energy Monitor program
3. Go to File > Open...
	4. Display 'Open' window
5. Select data file to load
	6. Retrieve data file
	7. Load data file into data table

Display Data

User Action	System Responsibility
1. Choose device from data table
	2. Retrieve record from data table
	3. Send device data to 'Calculations' class
	4. Calculate data
	5. Send calculated data to 'Graphing' class
	6. Display graphs and calculations
7. Update calculation input fields as desired
	8. Update graphs and calculations

Get Help

User Action	System Responsibility
1. Go to Help > Instructions
	2. Load Microsoft Word with file 'EnergyMonitorUserGuide.doc'
3. Gom to Help > Online Support (optional)
	4. Display 'Online Support' window

Discussion and Concluding Remarks

Our team found that the project description and specifications were not overly restrictive, allowing room for creativity and interpretation within the problem description. Each member of the team enjoyed this freedom. We were able to include the majority of the ideas originally brainstormed, which in turn led to an advanced application that incorporated many features.

An importance was placed upon all aspects of design during the entire project. However the design of the code may have been better implemented if the group had had a greater level of skill in programming with Java before the project commenced. This was not a hindrance but could have worked as an advantage.

On completing the project our group noticed the importance of keeping within the scope of the initial design project. After everything was completed we realised that we could have incorporated numerous advanced features, extended the range of options available and much more. However we believe that we did stay within the scope of the project and are happy with the results of our project.

On the whole our group was very pleased with our project and think that it effectively meets the requirements of the project with a strong connection between the design and construction of the project. Object oriented design as a whole helped us learn to effectively work together as a team in managing a project. The project itself gave us a good understanding and insight on what could be required in the real world.

Future Developments

Our project is versatile and utilises a modular design. Each class has delegated tasks which will ease any upgrading process or patch implementation. This was an important feature of the project because in the project description the project was required to "measure the power consumption and energy usage" of an appliance that is plugged into a piece of hardware. Although this was out of the scope of the project, our project was deisgned to be adjusted and upgraded to meet this requirement.

Our project was able to display chronological data, but due to time and scope restrictions we were unable to display real time data because we were not capturing real time data but rather static variables specified by the end user. If the software was implemented to measure real-time data the only class that would have major changes would be the Graphing class.

Due to the limited timeframe we were unable to ensure that the program was bug free, although under normal operation the program did not encounter any errors. A user that is not familiar with the program may come across bugs from, for example, entering a character into a textfield that is expecting an integer. With a few more weeks of programming we could have ironed out these bugs, however unfortunately we did not get around to it.

If given enough time, the user interface could have been better adjusted to a client's needs. Interchangeable background images could have been applied to suit different people's tastes. As the customer is the number one priority, the program could contain features such as flash animations and an online support guide for troubleshooting. Though this is not commercial program, it would be in our best interest to create a program that comes close to it.

References

General Research

During the Inception stage of the Miniature Unified Process (MUP) our group collected a wide range of useful information related to the project. These resources enabled our group to approach the project with a wide range of ideas, perspectives and thought processes. The links below where used for this research...

http://www.hermann-uwe.de/blog/measuring-the-energy-consumption-of-everything-you-own

http://www.thinkgeek.com/gadgets/electronic/7657

http://www.treehugger.com/files/2006/07/wattson_monitor.php

http://www.theenergydetective.com/features.asp

http://www.good-tutorials.com/tutorials/photoshop

Coding

During the construction stage of Miniature Unified Process (MUP) our group stumbled upon various hurdles in terms of coding the software. Although each member of the group had previously completed Object Oriented Programming, our skills in the java programming language where originally limited. The group did countless hours of research into the java programming language and on how to implement and manipulate code, to effectively achieve the certain aspects of design that we had incorporated in the Inception and Elaboration stage of the project. After completing the project i think each group member could honestly say that Object Oriented Design didn’t just teach them the design fundamentals but provided a high level of confidence in java programming.

Our group would like to make special reference to the open source graphing package by Leigh Brookshaw from http://www.java2s.com/Code/Java/Advanced-Graphics/DrawMathFunctionYourOwn.htm which was a great help, without it our program would not have incorporated such good graphing functionality.

The following references where a great help for our group in terms of programming...All the links below were visited on and off during the construction stage 02/04/07 - 11/05/07.

http://www.chka.de/swing/table/TableModelListener.html

http://forum.java.sun.com/forum.jspa?forumID=256&start=0

http://www.java2s.com

http://javaboutique.internet.com/tutorials/Java_by_Example/

http://www.javareference.com/jrexamples/viewexample.jsp?id=75

http://java.sun.com/j2se/1.4.2/docs/api/allclasses-noframe.html

http://javatechniques.com

http://www.javaworld.com/javaworld/javatips/jw-javatip81.html

http://www.javaworld.com/javaworld/

http://www.programmersheaven.com/mb/java/Board.aspx?S=B20000

http://www.zfqjava.com/docs/componentset/fontchooser.html

Wu, C. 2004. An Introduction to Object-Oriented Programming with Java. Higher Education. New York.

Hambly, A. 2002. Electrical Engineering - Principles and Applications. 2nd edition. Prentice Hall. New Jersey.

Documentation

During the semester a large amount of material is presented in lectures and online from the university covering all aspects of the projects documentation but our group also visited various other sources to obtain different perspectives and ideas about the documentation and design of the project..

http://atlas.kennesaw.edu/~dbraun/csis4650/A&D/UML_tutorial/class.htm

http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/

http://en.wikipedia.org/wiki/Unified_Modeling_Language

http://www.ibm.com/developerworks/rational/library/3101.html

http://en.wikipedia.org/wiki/Sequence_diagrams

http://www.softwarepractice.org/courseware/index.php/design

Instructor comments

Excellent start with your stakeholders, requirements,usage scenarios and use cases. Interesting diagram to show inter-relations between use cases. You might like to look at the "extends" and "includes" relationships between use cases. See reference [1] Lian 28th March

Post presentation session milestone: Very good set of stakeholders. Good description of user activity in usage scenarios. With use case descriptions, try to avoid using terms like 'array' which are really an implementation choice that should not appear in use cases. Instead refer to the domain of functionality, eg. "Save the set/collection of appliance data to file". Good to see your GUI layout. Good breakdown of responsibilities for each class. Overall, a fairly high level of work. Lian 4th April