<Names removed>
CSE 5236
Professor Champion
4/27/17
Green Thumb Final Report
Section 1 - Introduction
Approximately 2 percent of the United State’s population is comprised of farm and ranch families[1]. Despite a relatively small proportion of the population being involved in agriculture, investment in agricultural technology is booming and is seemingly becoming the next burgeoning niche where technology will cause a significant disruption[2]. One subset of the agricultural technology industry that has not made significant strides, however, is the mobile application space. Many farmers do not wish to go through a variety of different websites and applications to check for important information and keep track of their resources. It would be preferable for there to be a single application to provide farmers with relevant information and allow them to keep track of other important details. To address the lack of a single source for important data for farmers, the idea of the Green Thumb Android[3] mobile application was conceived.
The Green Thumb Android application provides farmers with three main, useful features. First, a farmer can keep track of the inventory on their farm through a convenient interface that allows adding new inventory items, editing of existing items, and deleting of existing items. Further, the current prices for crops and other commodities such as livestock is retrieved from a popular farming website called “Agriculture.com”[4] and displayed to the user in another section of the application. Finally, based on the farmer’s current location, weather data is also retrieved from the Yahoo Weather API[5] and shown to the user. By allowing a farmer to conveniently view important live information such as weather and crop prices, decisions regarding work schedule and orders can be made more quickly. Additionally, the inventory provides an incredibly quick way for farmers to keep track of all the important items on their farm. With these features, farmers can use Green Thumb to go about their work day more efficiently.
Section 2 - Design Process
Once the main features of the application had been brainstormed and agreed upon, it was vital to undergo an object-oriented design process to translate basic ideas into more concrete work products. The first step in this process was to identify the nouns that could potentially translate into classes or other structures in a programmatic space. Some nouns that were found when thinking about the application and how it relates to the domain were: farm, farmer (broken into owner and employee), forecast, current condition, inventory, inventory item, crop, livestock, machinery, tool, and commodity. Before breaking down and examining the nouns, various verbs that could also relate to the application were also identified; some of the more significant verbs were: view, add, delete, edit, input, modify, sign in, sign out, and display.
After examining the nouns that were found further, some were removed since they already fell into a category covered by another noun. For example, crop, livestock, machinery, and tool are all types of items that would be kept track of in an inventory, so these nouns fell in the category of the “inventory item” noun. Commodity was fine as its own noun as it had the connotation of a price associated with it, as opposed to the other items. Finally, “current condition” (in terms of weather) is also a type of “forecast”, so “current condition” was removed. This removal and consolidation of nouns aided in coming up with the important domain objects and classes later on as design was translated into implementation. For the verbs similar removal of duplicates was performed as with nouns as it wasn’t necessary to have two verbs that had very similar meanings such as “edit” and “modify.” Thus the important verbs that were leftover were: view, add, delete, edit, and display. It should be noted that some verbs such as display applied to multiple nouns such as commodity and forecast.
Based on these nouns and verbs, classes were architected. For the nouns, classes such as Farm, Employee, Owner, Forecast, Commodity, and StockItem were thought of. Farms, Owners, and Employees would be collaborators, but in the sense that they were associated with each other in a way, not that there would be any explicit collaborations between these domain objects. Responsibilities for an Owner or Employee would mainly be focused on sign in and sign out. After further consideration, it was decided that Farm was not needed as a class, but simply as a database construct for associations. Forecast and Commodity would be classes that held information regarding the weather forecast and information regarding a commodity, respectively. These two classes would have their objects’ values dynamically updated from live data. Thus these classes main responsibility would come with the verbs display and update. For the StockItem class, the verbs add, edit, and delete are significant as these are the three main actions that would be desirable for keeping track of an item in inventory (the domain entity that StockItem represents).
Our initial thoughts about the database schema was that owners, employees, and inventory items were the domain objects that needed to be stored persistently and that all of them needed to be related to a particular farm. Further, since the idea of different users accessing the same data was present, a remote database would be required. Thus, the relational database schema initially had 4 main relations (not including join tables): STOCK_ITEM, EMPLOYEE, OWNER, and FARM. The STOCK_ITEM relation would represent the inventory items and EMPLOYEE and OWNER would represent employees and owners of the farm, respectively, holding authentication data. All three of the aforementioned relations would relate to a FARM through foreign keys so that only data linked to a farmer’s own farm would be displayed, mirroring the collaborations that were mentioned previously. It should be mentioned that these were simply the initial thoughts regarding the database schema. As will be mentioned later on in the discussion of going from design to implementation, this is not the database schema that was kept through the implementation of the application. The database schema was simplified to only keep the STOCK_ITEM relation as forethought regarding non-functional requirements and usability arose when going into the implementation phase of the application.
Section 3 - Translating Design to Implementation
Though the design of the application was well laid out, a major gap in translating the initial design to a final implementation was brought to the forefront after more careful consideration regarding domain in which this mobile application would be used. One of the main issues that was not considered in the design phase was the lack of connectivity in rural areas[6]. This issue became vitally important as non-functional requirements were considered early on in the implementation phase. For frequent operations such as login or keeping track of inventory, the lack of network connection could pose a major inconvenience to users of the Green Thumb application. Infrequent network operations such as checking the weather or price would be bearable for a user as these types of live data are checked on a less frequent basis, however, logging in and out of the application, as well as updating inventory items would occur much more frequently. Reconsidering the initial design and consulting domain knowledge from a team member with a farming background, it was decided that the database would be made local (on the device) instead of remote and that login features would be removed. The lack of login was justified because, according to the aforementioned team member’s farming experience, farms aren’t very large operations anymore, so one device for the owner should be sufficient for keeping track of inventory as well as checking the live data. This change also resulted in a simplification of the database schema as only the STOCK_ITEM relation was needed anymore since all other relations were for the purpose of login and linking a farm to inventory items in a remote database. The major domain entities left after the changes were Commodity, Forecast, and StockItem and all other functional and nonfunctional requirements of the application were still met.
Besides the changes discussed, translating the design into implementation was a straightforward process.The database schema was plainly laid out in the design phase and could be converted in a direct manner to the schema of an actual database (even with the removal of certain relations as discussed previously). The Commodity, Forecast, and StockItem domain entities that remained also mapped directly to classes in the application with attributes and methods, for the most part, matching those that were illustrated by class diagrams in the design phase. After the domain entities were translated into programmatic members, the architecture of the Android application itself was set up. An Android Activity[7] was used to host Android Fragments[8] for each of the major features of the application (inventory management, commodity prices, and forecast display). A bottom bar navigation system was also set up so that users could conveniently navigate across the three major interfaces and weren’t constrained by any kind of workflow in the application. Once the navigation flow and overall architecture of the application was set up, the remaining work was to retrieve live data, set up proper database operations, and get the proper user interfaces established.
Section 4 - Suggested Changes and Improvements
The biggest change to the design process that would be made in retrospect is to take a more in-depth look at the nonfunctional requirements during the design process, especially in regard to usability and availability. If the team had considered availability ahead of time, the issues that had been encountered when translating from design to implementation could have been avoided (albeit the design would have been different in the first place) or at least lessened. An example of this can be explained when considering the issue with availability in a rural area when trying to constantly perform operations on a remote database. An alternative that was thought of, in retrospect, was to schedule updates on the database at certain points in the day instead of interacting with the remote database after every update so that the user is not left waiting after every day. Though concurrency problems may have arisen with this approach, these problems may have been able to be addressed and the multiuser functionality of the application could possibly have been re-introduced.
After finishing the implementation of application, several usability issues were also discovered. For example, for inventory management, once many items are contained in an inventory, it can become tedious to scroll through the interface to find a specific item. In hindsight a search feature in inventory management could have been established as a use case during the design phase, translating to an actual search feature in the application. Had usability been considered more in the design process, changes could have been made or features could have been added so that the user could more conveniently use the Green Thumb Android application.
More detailed exploration of the domain could have also been performed in the design phase to explore possibilities for other features that could have been useful in the application. Currently, there are three main features that are fairly useful for a farmer and easy to interact with, however other possibilities were also thought of after the design process had been completed. For example, a scheduling feature could have been conceived in order to help organize a farmer’s day. Assignments of tasks and other activities that need to be performed could be done through an application according to the time.
Besides considering the usability for application as well as adding new features, enhancements could have been thought of for the existing features. One example of such an enhancement is sending a notification once a certain commodity that a farmer had subscribed to fell before a certain threshold. This could provide a convenient way for farmers to maximize their economy by providing a convenient way for a user to know when a commodity is at an acceptable price for them to buy. Further, for the weather, more information could have been displayed that may be convenient for a farmer. Currently, humidity and wind statistics are not presented to the user (condition, the high temperature, and the low temperature are displayed). The addition of these metrics of weather could certainly aid farmers further in planning out their day as a high humidity could be cause for not performing strenuous work on a day and high wind speed could be cause for avoiding working with certain, sensitive machinery.
References
[1] Fast Facts About Agriculture, Forbes,
[2] The Next Phase for For Agriculture Technology, Forbes,
[3] Android Open Source Project, Android,
[4] Commodity Prices, Agriculture.com,
[5] Yahoo Weather API, Yahoo,
[6] Technology Is Improving, So Why Is Rural Broadband Access Still a Problem?, U.S. News,
[7] Activity, Android,
[8] Fragments, Android,