Prototyping, storyboarding, designing UI
Proof of Concept with all features implemented
Improving Voice UI and polishing User Experience
This is the second iteration of LeChefu.
This pattern ensures that only one object of a class is ever created.1 It is useful when exactly one object is needed to coordinate actions across the system. Since the Singleton Pattern is considered an anti-pattern for introducing a global state in the application and possibly making the code tightly coupled and more difficult to change, we were careful not to use it too often, but only when we saw it was most advantageous. We created a Singleton class by making the constructor private, disabling cloning, disabling extension and creating a static variable for the instance of the class. With Singleton classes, we can control access to a shared variable when the whole system only needs one instance of this class.2 Although it gives the advantage of having a static instance, we are able to specify creation logic for our Singleton class, unlike in a static class. A disadvantage of this pattern is that the class cannot be subclassed.
We used the Singleton class for the classes of our API engines. This prevented the system from connecting to the API multiple times within one session, which would be costly over a long period.
With the Facade Pattern, we can provide a simplified interface to a complex problem carried out by a larger body of code. It is a structural Design Pattern used with classes that require the use of numerous methods that are complicated to use or difficult to understand.3 The newly-created Facade class is a “wrapper” that provides easily understood methods that are simple to use in comparison. These methods provided access the subsystem on behalf of the class using the Facade, hiding the implementation details. Furthermore, it encourages loose coupling between the subsystem4 and its clients, making our system easier to maintain and update. On the other hand, use of the Facade pattern could affect performance of our system, as it adds a layer of indirection.5 Therefore, while implementing this, we analysed our code to ensure that the overall performance was not being affected by using this pattern.
Our use of Facade Pattern is most evident in our implementation of the grocery lists feature. Our Grocery List engine allows users to create, delete, update and access their grocery lists by calling a series of methods from the GroceryListEngine class. As this was starting to make our Main class too convoluted and the calls to the class were expanding while we added more functionality in, we decided to use this pattern to enable the Main class to access each function just by calling one method.
With Java’s JUnit, we used unit testing to test individual components of our system before integration and functional tests. The purpose of unit testing is to “validate that each unit of the software performs as designed”.6 Units are the smallest parts in the system that we can test and usually have a single output. We have chosen individual methods as our units and have written unit tests for them with ordinary and edge cases.
After all features have been unit tested, we performed integration testing to discover that all major parts of the system work together well.
We employed bottom-up integration testing, which is integrating and testing the lowest-level units first, followed by higher-level components.
We used 2 methods to perform functional testing on SOTA:
Boundary value analysis helped us test how SOTA responds to extreme user inputs e.g. creation of grocery lists of various sizes. We performed boundary value analysis to ensure that the system does not break under such user input. Exploratory testing allowed us to test various features of SOTA which were stated in the functional requirements documentation. This testing method was used to ensure that all features worked properly and that they conformed to the stated system goals in the initial design phase.
We performed 6 tests on SOTA which are explained in detail below:
1) Grocery List creation: We performed a test to ensure that the user was able to create simple grocery lists through voice UI. This test was important as it was one of the basic functional requirements of SOTA. Grocery lists were created in various environments with differing noise levels. SOTA was able to comprehend what the user meant most of the time and hence this test was a success.
2) Update Grocery List: We also performed a test to ensure that the user can easily update their grocery list. The initial test involved updating the grocery list with a single item. To test the flexibility of the system we updated the grocery list with 50 items and SOTA did just fine. This test was also a success as SOTA had no problems dealing with a huge list of items. An important aspect of grocery update was to ensure that SOTA understood the ingredients spoken by the user - we can comfortably say that SOTA successfully comprehends these ingredients most of the time.
3) Recipe suggestions: Another functional feature we tested was whether SOTA can suggest valid recipes depending on the ingredients that the user has. We performed a simple initial test with 3 ingredients to test whether SOTA returns valid recipes on simple user input. To test boundary values on this feature we provided SOTA with 15 ingredients and SOTA was easily able to provide the user with valid feedback on potential recipes. This test was a success too.
4) Image recognition: SOTA should be able to recognise ingredients for the user. This can be helpful when the user does not know the ingredient. We tested this feature by varying the light levels under which the ingredient was shown to SOTA. SOTA performed reasonably well and detected the ingredient correctly in most cases. After performing various tests on SOTAs image recognition feature we decided that it correctly works.
5) Unit conversion: SOTA should be able to convert between various units e.g teaspoons to milliliters. We performed various tests on SOTA to ensure that the unit conversion was working correctly. We tested all the unit conversions with extreme values and SOTA returned accurate results. We deemed this test to be successful as it worked correctly under all test cases possible.
6) Timers/Alarms: The system should be able to keep track of timers set by the user. To check this feature worked correctly, we started our test by setting various timers. SOTA kept track of timers correctly and alerted the user once the timer was over. Timers were created of various lengths and at the same time. This test was successful.
After performing a variety of tests on SOTA, we believe that SOTA is functioning correctly as required. It conforms to the goals set out with the client at the beginning of the project. We have tested various extremes and seen how SOTA responds to such user input. When testing SOTAs feature for recipe suggestion, we provided SOTA with 15 ingredients - the system took a while to provide feedback to the user but we believe that even under extreme cases SOTA was considerably efficient. SOTA passed all test cases and hence functional testing has been a success.
[1] kamranahmedse (2017) Design Patterns for Humans. Available at: https://github.com/kamranahmedse/design-patterns-for-humans#structural-design-patterns (Accessed: 26 February 2017).
[2] Emmatty, J.T. (2011) Singleton pattern – positive and negative aspects. Available at: https://www.codeproject.com/Articles/307233/Singleton-Pattern-Positive-and-Negative-Aspects (Accessed: 26 February 2017).
[3] Carr, R. (2008) Facade design pattern. Available at: http://www.blackwasp.co.uk/Facade.aspx (Accessed: 26 February 2017).
[4] Javatpoint (2011) Facade pattern. Available at: http://www.javatpoint.com/facade-pattern (Accessed: 26 February 2017).
[5] Mccreath, E. (no date) Facade design pattern. Available at: https://cs.anu.edu.au/courses/comp2500/notes/10facade.slides.pdf (Accessed: 26 February 2017).
[6] Theme and Powered, C. (2016) Unit testing. Available at: http://softwaretestingfundamentals.com/unit-testing/ (Accessed: 26 February 2017).