UML Use Case Diagram The use case diagram is used to identify the primary elements and processes that form the system. It defines a goal-oriented set of interactions between external actors and the system. The primary elements are termed as “actors” and the processes are called use cases or actions. Actors are entities that will utilize the application in order to complete a task. An actor maybe a class of users, roles users can play or other systems. Cockburn (1997) distinguishes between primary and secondary actors. A primary actor is one having a goal requiring the assistance of the system. A secondary actor is one from which the system needs assistance. Since this project focuses more on the image processing phase, this particular use case diagram will focus on the secondary actor i.e. the web camera and its part in the functionality of the software. 4.5.2 Activity Diagram The process flows in the system are captured in the activity diagram. An activity diagram consists of activities, actions, transitions, initial and final states and guard conditions. It is used for modeling the logic captured by a single use case scenario(Amber (2003)) Software testing is the process of analyzing a software item to detect the differences between existing and required conditions (that is, bugs) and to evaluate the features of the software item [19, 20]. Software testing generally involves Validation and Verification processes. Verification is the process of evaluating a system or component to determine whether the products of a given development phase satisfy the conditions imposed at the start of that phase [21]. Verification activities include testing and reviews. Validation is the process of evaluating a system or component during or at the end of the development process to determine whether it satisfies specified requirements [21]. Once the code has been implemented, the testing of the code is carried out. Testing ensures that the software developed functions as expected. There are two basic testing techniques available, Black box testing and white box testing. The white-box testing focuses on the internal structure of the code. The white box tester (most often the developer of the code) looks into the coding of the system that’s has been implemented to look for any errors by writing test cases. Here the inputs are chosen specifically to determine an appropriate output the result can be evaluated more clearly as said in “Redstone Software Inc” (2008). White-box testing is often used for verification. Black-box test design is usually described as focusing on testing functional requirements. Knowledge of the systems code and programming knowledge is not required. The test cases are built around what the software is supposed to do. Valid and invalid inputs are taken to determine the correct output as discussed in “Redstone Software Inc” (2008). Black-box testing is often used for validation. The black-box testing technique here was applied to test the stated functionality, which ensures that the right product has been built. This type of testing aims to uncover errors which include interface errors, performance errors as well as initialization and termination errors to name a few which are relevant to this project (Pressman, 2005). Table 6.1 shows the Black Box tests that were implemented for the code developed, tests labeled “pass” have passed the test at the first iteration of the code. Nearly all of the test cases passed in the software. Personal Reflections This research project was a great learning experience as it made me realize my strengths as well as areas where I could improve my skills for future projects. This project was the most challenging of all projects completed in the past but yet enjoyable. Even after knowing the complexity of the project, the eagerness to explore a whole new field of technology was what led me to choose the topic of touch less interaction through gesture recognition. I feel that my strength have been in making my code. The code developed in the project are completely from scratch so developing the code has been challenging but has made my realize that I do have the ability to code, before this project I saw coding as tedious but this project has completely changed my view on coding and I have embraced this change. However this project does not completely meet the initial aim that was set out for this project, I have been pleased with how far I have come from having no clue about what programming environment to use to gradually designing small parts of the system to make it work together. My weakness however is my software & time management. Time management was one of the main weaknesses of mine. I feel that I could have handled this project much better in terms of sticking to a scheduled completion time or sticking to the approaches that I have specified. I did manage to stick to the Waterfall model of development used but I feel that this could have been done better. The time required for the implementation and testing was underestimated which led to the incomplete development of the software and poor testing applied. I spent maximum amount of my time familiarizing with the new programming language and development tools and then developing the code. In future, a more realistic plan for completion and execution could be used to avoid disappointment and delays in task completion. As Android is a phone platform and generally only has a single core processor, the number of threads needs to be kept to an absolute minimum as ultimately only one thread can be executed at any one time. Generating threads is also a very expensive exercise and so should be avoided as much as possible. Android also does not let any thread other than the User Interface thread update the UI, and if a piece of code tries, a concurrent access exception is thrown and the program is closed by the Android System. Luckily all is not lost and Android has a structure called an ASyncTask, which contains three generic methods: onPreExecute, doInBackground and onPostExecute. Any code executing in onPreExecute or onPostExecute executes on the UI thread, allowing the UI to be modified and any code in doInBackground runs on an already created background task thread that pools all background tasks and executes them at once. ASyncTask’s are heavily used throughout the Android App as they are by far the easiest way to do UI updates and run computationally expensive and slow tasks in the background without losing the responsiveness of the UI. Event Handling – “Intents” and Broadcasts As already mentioned, every Activity in Android is independent of one another so messages must be passed as Broadcasts containing Intents. An “Intent” usually describes where the message should go (specified by package and/or class) and also contains any other information the programmer wishes to send. As a tabbed interface was chosen as the starting point of the UI, a problem emerged in the design where there was no way to programmatically change the current Tab, as the tab is a separate Activity from what is actually displayed in the tab. For example, from the friend tab a user selects a friend and wants to view their friend’s location on a map, the Tab Activity needs to catch that this has happened, switch tabs and then the Map Activity must process the information and display the friend’s location. The final design solution was to use broadcasts and use the Tab Activity as a controller to route requests. The Interaction Diagram below shows how this would occur: Background Service The background service was one of the trickiest designs to get correct due to a lot of conflicting information about how long they should stay active for and how the location should be obtained. The original plan was to have a never ending service that registered a broadcast receiver to listen for location changes (broadcast by the Android OS), but after testing it was found to use too much battery and the frequency of the “Location Change” broadcasts was intermittent. The final design was to use a short lived service that starts based on a timer and finishes once it has performed its task. The service also has to obtain a “Wake Lock” from the Android System. Normally the Android OS turns the phones CPU off if no work needs to be done to save battery, but this unfortunately stops background services as well. Using the Alarm method, the service is started at a user set interval and it then obtains a “Wake Lock”, stopping the phone sleeping until the service’s task is finished and the location data is sent via POST to the Web Service. Once finished, the service stops and the “Wake Lock” is released, turning the phones CPU off if the phone was asleep. The service will be started again automatically by the Alarm at the next interval. Location Method The Android Location API was used to obtain the phones location in the Location Service. The programmer has the choice of using the GPS or Network Location, which uses a combination of Cell Tower information and nearby Wi-Fi access points automatically. This system by default only uses the Network Location method, as it is usually accurate enough at around 60m, as well as using almost no battery. The user can enable the background service to use GPS if they wish. Android has no way checking for a location for a specified length time, so a class was designed that uses timers to only listen for a specified time or until a location update is found. This allows fine control over how often the user’s location is updated which in turn allows the user to decide how much battery they are willing to sacrifice to background updates. Push Messaging Through the use of a third party library called Xtify it was possible to add true Push Messaging to Pikoo. When the user registers, they are given a unique push key by the Web Service, which is then registered on the Xtify Service running on the phone. The user is notified instantly of Messages and Shared Markers via a notification in the Android Notification tray. If the user selects the notification, an “Intent” is broadcast to start Pikoo and download the Message or Marker and then display either the Message Screen or Map Screen with the new information. Only downloading the information when the user actually requests it, rather than when the push message is received, helps to conserve battery life as messages wont constantly be downloading in the background. The MySQL database on the server also keeps track of all messages that have been downloaded by the App so a request for new messages will only ever return new messages keeping data transfer to a minimum Views This section details the final design of each view activity as well as how they function. All views in this project are generated from XML files that have been created by hand and loaded via the “setContentView(R.layout.view)”. All views have been designed using fluid layouts as the application must function in both landscape and portrait modes as well as over a large range of differing resolutions. All sizes have been specified in “sp” units instead of “px” units. SP units are screen size independent units allowing the design to look the same on any platform. The screen allows a user to register for the service, login using their existing credentials or recover a lost password. The recovery option launches the Android browser and displays the Pikoo Website which handles the password recovery. The view cannot use an image for the logo as images do not scale well and the app would have to target a specific resolution on Android. Instead the logo was designed using a box with a repeating background image and the text is horizontally and vertically centred using built in android functions. Detailed Use Case Diagram The Use Case Diagram is shown below that was used as a starting point for the design. A Use Case was chosen as it lists all the functionality the system must have. The Activity Diagram is shown below that was used to show message flow one activity to another. A Use Case was chosen as it lists all the functionality the application must have.