RESEARCH WORK

BiomaSoft: computer system for the monitoring and evaluation of food and energy production. Part II

Julio Ramiro Quevedo-Benkí and Jesús Suárez-Hernández

Estación Experimental de Pastos y Forrajes Indio Hatuey, Universidad de Matanzas, Ministerio de Educación Superior Central EspañaRepublicana, CP 44280, Matanzas, Cuba
E-mail: julio.quevedo@ihatuey.cu

ABSTRACT

In order to support and facilitate the monitoring and evaluation (M&E) of the integrated food and energy production in Cuba, BiomaSoft was designed, a computer system for the M&E of integrated food and energy production in Cuban municipalities. The objective of this paper is to provide a description of the main aspects in the implementation and development of such system, for which its use cases are textually described and the specific design class diagrams for each one are provided. As a whole, the detailed aspects show the way in which the different actors should interact with the BiomaSoft system, tailor-designed for the support of M&E. Likewise, all the compiled information allowed to design and construct a robust database, capable of supporting the large quantity of information the system should manipulate; and also to reach a deep understanding of the functioning and capacities of the system, for their later display.

Keywords: database, models, development project.

The utilization of renewable energy sources, with emphasis on liquid and gaseous as well as solid biofuels has currently reached high development worldwide (FAO, 2008; IEA, 2013; IRENA, 2014). In Cuba in the last five years, advances have been achieved too in the development of these biofuels (MINEM, 2014; Suárez et al., 2014), in order to contribute to food security, energy sustainability and environmental sustainability at local scale.

The international project «Biomass as renewable energy source for Cuban rural areas (BIOMAS-CUBA)», funded by the Swiss Development and Cooperation Agency (SDC) and led by the Research Station Indio Hatuey, in six Cuban provinces, contributes to this purpose. This project develops experiences for the integrated and sustainable food and energy production that needs to be monitored and evaluated, which can be favored by a software program that facilitates and automatizes all the complex process of information management.

With that objective diverse computer systems for project monitoring, control and/or evaluation were studied, such as the ones developed by Pellerin et al. (2013), Acebes et al. (2014) and Hazir (2015), but they are focused on computerization projects and designed for developed countries. For such reason, the authors decided to tailor-design, develop and implement BiomaSoft, a computer system to support the M&E of the integrated food and energy production, which does not have antecedents in Cuba.

The goal of this paper is to provide a description of the software development process that took place in the implementation of the system¹.

Methodology

Description of the BiomaSoft system for M&E

From the functional and non-functional requirements, the use case diagram of the system, the actors and its general description, and following the work flow of the Rational Unified Process (RUP) methodology, provided and described in part I (Quevedo and Suárez, 2015), all the functionality of BiomaSoft is displayed in three main use cases: «Managing system data», «Managing direction strategies» and «Managingfollow-up records». Below a detailed description of each one of them, as well as their specific design class diagram, derived from the generic BiomaSoft Design Class Diagram (Quevedo and Suárez, 2015), is provided, through a scheme that responds to the methodology used. This delineation will be useful for a better understanding of the system functioning, and to establish clearly who interacts with it and how they do it.

Table 1 shows the basic aspects of the textual description of the use case Managing system data. The identifier of the use case, the actors who interact with it, a brief summary of its functioning, the priority it will receive by the system, and the conditions that should be fulfilled after the use case has been needed and satisfactorily used, are thus grouped.

The «Normal flow of events», thatis, the performance of the system in response to a requestby the actor oruser, is shown in table 2. Thus, each action of the actor, in successive order, and the respective response of the system to eachone of them are listed. A prototype of graphic interface which allows to visualize the aspect the system will have and the actions the actor could perform is also presented, in the specific section of the use case Managing system data.

Table 3 shows the section that allows to eliminate a datum from the system. Associated to the Normal flow of events, itis a continuation of thelist of eachaction of the actor and the respective system response, after the actor previously accessed the option Eliminate datum (see table 2).

The section that allows to edit a system datum is described in table 4. It is a continuation of the list of each action of the actor and the respective system response, after the actor previously accessed the option Edit datum, as described by the normal flow of events (see table 2).

Table 5 shows the section which allows to add a new datum to the system. Associated to the Normal flow of events, it is a continuation of the list of each action of the actor and the respective system response, after the actor previously accessed the option New datum (see table 2).

In case that during the Normal flow of events of these above-described sections the system verifies an error in the introduced data, an alternative flow is taken up to prevent damage in the manipulated data and report to the user. Table 6 describes an alternative flow for edition or addition, in the face of an unexpected event.

The design class diagram (fig. 1) is based on the one proposed by Quevedo and Suárez (2015), but focused on the use case Managing system data a similar diagram is shown for the other two use cases. This diagram allows to organize, as proposed by the architectural pattern Model View Controller (MVC), the classes and components used in such use case. This facilitates structuring the components, according to Reenskaug et al. (1995), Jacobson et al. (1999) and ISO/IEC (2014), as shown below:

Model: composed by the ORM (Object Relational Mapping) Doctrine, used by the framework (Symfony) for data management and processing.

Controller: composedby a frontal controller GestionarProyecto.php, in charge of receiving requests (generally URL) and, using the Symfony components (package that encapsulates the framework functioning), determining the module Actions and the action it should invoke, in order to respond to the received request.

View: composed by files with suffix success (ListarDatosSuccess, NuevoDatoSuccess, and EditarDatoSuccess), in charge, along with the Layout, of adhering the results of the actions, later used by the frontal controller to construct the client pages GestionarDatosIndex, which are the ones that will be ultimately shown to the user.

Use case Managing direction strategies

Textual description of the use case

Table 7 shows a textual description of the use case Managing direction strategies. The use case identifier, the actors who interact with it, a brief summary of its functionality, the priority it will receive by the system, and the conditions that should be fulfilled when the use case has ended, are grouped.

The normal flow of events is shown in table 8; thus, each action of the actor, and the respective system response to each of them, is listed consecutively. A prototype of graphic interface which visualizes the aspect the system will have and the actions the actor could perform are also provided, specifically in the use case Managing direction strategies.

The section which allows to eliminate a direction strategy is described in table 9. It is a continuation of the list of each action of the actor and the respective system response, after the actor previously accessed the option eliminate strategy, as described by the normal flow of events (table 8).

Table 10 shows the section that allows to edit a direction strategy. Associated to the normal flow of events, it is a continuation of the list of each action of the actor and the respective system response, after the actor accessed the option Edit strategy (see table 8).

The section that allows to add a new direction strategy is described in table 11. It is a continuation of the list of each action of the actor and the respective response of the system, after the actor accessed the new strategy option, as described by the normal flow of events (table 8).

Table 12 describes the alternative flow for the edition or addition, in the face of an unexpected event, in case that during the normal flow of events of the above-described sections the system verifies some error, to prevent damage in the manipulated data and report to the user.

Figure 2 shows the design class diagram, which is based on the one proposed by Quevedo and Suárez (2015) and is focusedonthe use case Managing direction strategies.

Textual description of the use case

Table 13 shows the basic aspects of the textual description of the use case Managing follow-up records. The use case identifier, the actors who interact with it, a brief summary of it, the priority it will receive and the conditions that should be ful filled after the use case has been used.

The normal flow of events describes the performance of the system in response to a request of the user (table 14). Thus, each action of the actor and the respective response of the system to each one of them are listed; a prototype of graphic interface which visualizes the aspect the system will have and the actions the actor could carry out in the use case Managing follow-up records, is also shown.

Table 15 shows the section that allows to eliminate a follow-up record. Linked to the normal flow of events, it is a continuation of the list of each action of the actor and the respective response of the system, after the actor accessed the option Eliminate record (table 14).

The section that allows to edit a follow-up record is shown in table 16. It is a continuation of the list of each action of the actor and the respective system response, after the option Edit record described in the normal flow of events (table 14) was accessed.

The section that allows to add a new follow-up record (table 17) is associated to the normal flow of events and is a continuation of the list of each action of the actor and the respective system response, after the actor accessed the option New record (see table 14).

In case that during the normal flow of events of these sections the system verified some error, an alternative flow (table 6) is taken up, to prevent damage in the manipulated data and report to the user.

The design class diagram of the system (fig. 3) is based on the one proposed by Quevedo and Suárez (2015), but focused on the use case Managing follow-up record.

With the different definitions, concepts, entities and their relations, it was shown who interacts with BiomaSoft (project managers and monitoring and evaluation specialists at national and local level) and how they do it.

The construction, presentation and analysis of the diagrams, models and descriptions shown allowed to design and construct a robust database, capable of supporting the large amount of information that the system must manipulate.

Likewise, a tool was obtained to support the monitoring and evaluation of the integrated food and energy production; and a better understanding of the physical and logical distribution of such production was achieved, which allowed to reach a deep understanding of its functioning and capacities, for its later display.

Received: November 30, 2016
Accepted: August 25, 2017