Domain Model

Before going into the specific solution implementations, the domain objects involved and how they interact were visualized in a domain model. These domain objects are the necessary elements involved in tackling the problem. They consist of users, plants, plant types, diseases, logs, classifications. Figure 14 below shows the visualization of these elements and the interactions between them as a domain model. However, this model was altered throughout the project and does not represent the final version.₇

Figure 12: Sketch of problem domain model

Domain Model

It is the base for the data structure and design of the implementation. Since this model has such an important role, it is necessary to think this model through. Making a change in this step of software development can cost a lot of time as the whole system is built on top of it. This means that most of the time a redesign of this model influences many functional levels of the software. Therefore, a lot of code must be written or changed to support this redesign.₇

v    User

The first domain object that is part of many problem domains is the user entity. This entity represents the end-user and their related information. It also represents the input provider of the system, trying to achieve a user goal based on interactions in the problem domain. This user has one relational link with the PLANT domain object. As the user can own none or more plants in this implementation.

v    Plant

The next entity is the center piece of the model. It represents a plant that is owned by a user, as seen in the previous paragraph. It also has relational links with the “plant type” and “log” entities. The link with plant type implies that one or more plants represent a single plant type. Furthermore, the link with log indicates that one or more plants can have none or more logs. The plant entity includes information that describes it, consisting of a name and image URL.

v    Plant Type

This entity is self-explanatory. It represents the type of plant a plant can be. For example, a plant can be a “Tomato plant” or a “Grape plant”. It also has a relational link other than the one with a plant entity, explained in the next paragraph.

v    Problem

An entity that represents the disease or deficiency a plant can have. However, in the final model it is related differently. Here, one or more problems are related to a single plant type. For example, a “tomato plant” type can have the disease “early blight” or “spider mites”. The other relational link of a problem is described in the next paragraph. Furthermore, a problem contains data that describes it, consisting of a name, images location, and remedying advice. The name of this domain object is not perfect as it can resemble both diseases/deficiencies and healthy plants, not only problems.

v    Classification

An entity that represents a prediction of a problem. For example, a classification is an instance of the “early blight” problem. It’s relational link with a log is that up to three classifications can be part of a log. This log entity is explained further in the next paragraph. In short, a single classification object is used as a link between a log and a problem.

v    Log

This entity represents a time-based snapshot of a plant’s state. It contains up to three classifications representing problems or the lack there of. The user that created the log for a plant compares and chooses the correct classification based on similarities of symptoms and problem information once these are available. This information can be gathered through the classifications as they link a log with a problem. After choosing the classification, it becomes the “chosen classification” for this log. For example, a user creates a log for his tomato plant. The log is processed and contains three references to classifications. The user compares these classifications with the symptoms he sees on his plant and picks the one with the most similarities, “Septoria leafspot”. The log now has a “chosen classification” that references to the problem “Septoria leafspot”.

v    Request

This final entity is used to pass a picture URL and a log reference to the AI diagnosis engine described in section 6.5. This is used as a request to process a new log and provide it with up to three classifications for the user to compare and pick from. As soon as this request has been processed by the AIDE it is deleted. How this works exactly will be explained in Chapter 3’s “AIDE Implementation” sub-chapter.

Implementation Designs

Both implementation that were created for this bachelor thesis use parts of the domain model as reference to interact with each other. These implementations have their own internal software design patterns as they fulfil different tasks within the solution architecture. These individual designs are covered in their related chapters.