propose that reactive systems are those that give a continuous response to stimuli from their environment, both the processing and the results obtained are driven precisely by the inputs given by their environment [1]. In the case of web systems, determining the stimuli that occur at a certain moment, for a user, becomes a challenge because the combination of software and hardware used cannot be defined. To develop a reactive web system, we may adopt a base architecture to implement them in two layers: Front-end, which has the user interface, and Back-end, which considers functionality and management on data [2]. At the Front-end level, various libraries and frameworks have been created, such as React JS [3], whose purpose is to deal with the stimuli of a user.
Reactivity appeared to us as an NFR (Non-functional Requirement) [4] during an ecommerce project [5]. In this project, we reused code from Yin's GitHub [6]. Through the analysis of Yin's architecture, we delve into the React paradigm, which led us to various sources of information such as the Reactive Manifesto [7], The Reactive Design Patterns [8], and React JS' own documentation [3]. The cited literature uses the NFRs: responsive, resilient, elastic and message-oriented, among others, to satisfice2 [4] a Reactive System. This work draws from these information sources to elicit Reactivity as an NFR, which are modeled for the e-commerce application (Figure 1). With the focus of linking the information sources on React with the Yin's code [6], we modeled, using a viewpoint strategy [9][10], the e-commerce project as to satisfice Reactivity.
Our article is structured as follows. Section 2 briefly cite related work on reactive approaches. Section 3 establishes the objectives of our investigation. Section 4 details the the development of the i* model, which was built using the iStar 2.0 tool, piStar 3 . Finally, in Section 5 we present our conclusions about the work done as well as the future research.
To the best to our knowledge, reactivity is not being dealt from the NFR framework [4] point of view, which is building a software application with NFRs as first-class requirements. Existing work is focused on concurrent and distributed systems that uses a Rebeca modeling language for formal verification [11] [12]. Other works focus is on safety-critical embedded systems which being safetycritical systems uses reactive modeling approaches such needs the aware contract language CoCoSpec [13] and ScenarioTools [14].
Regarding existing words on i*, we found that our work agrees with [10][15] [16] in the use of collaboration as an important technique for better requirements engineering, particularly for a modeling that represents a common vision.
O1. React as an NFR can be operationalized by using React JS. O2. Organize NFRs and Operationalizations existing in sources of information related to Reactivity using an intentional modeling.
O3. Create dependency relationships between the Reactive capabilities of React JS and the actor's responsibilities identified for the e-commerce application.
According to Priola [17] when we are in a subjective research, we can perform an explanatory research to understand the relationships existing on diverse aspects of an issue. As our work uses viewpoints [9] as a mechanism to perform a collaborative model, then we are dealing with a subjective task which shows personal perspectives and interpretations, in our case, we based on examinations of documents [3][7] [8]. Following we detail the process to achieve a consensus on the React JS library actor we modeled to meet the reactivity NFR and other NFRs that contributes with it, as well as operationalizations (tasks).
Using viewpoints [9][10] for the understanding of the Reactivity quality, we carried out nine different individual elicitation based on the mentioned sources [3][7] [8], this individual work was given to allow each elicitor to create his/her model. Of the nine, we verified that only seven shared the main qualities in the React Manifesto [7]. Some of these i* models are shown in the project repository [18].
To make a consensus model, we collaboratively [10] elaborated two relationship maps, the first links elicited qualities to the main qualities of the Manifesto (Table 1). The second links project goals to the elicited qualities (Table 2).
In order to build a unique model, we established a threshold for a consensus, that is, there is a consensus if at least three authors share the same point of view. Then, the relations among qualities with help (1) in table 1, were not considered.
For the identification of tasks, we use as a mechanism to set the goals as questions and then look for the tasks that give answers. Reactive Design Patterns [8] was chosen as a source of information, since the tasks should give us more concrete solutions, and we could relate them to the e-commerce project [19] code. The elicitation and modeling of tasks was performed in meetings where we, collaboratively [10], defined the tasks for the goals previously identified.
For example, for the goal called "Have the inputs of the services rendered", the tasks identified in the design patterns were "Get the inputs" and "Create a composition of inputs". This means, when our system receives inputs which will mean a change for it, through a composition, will perform an update of the active component, avoiding updating everything together, thus optimizing resources and time. The identification of the other tasks in Fig. 1 followed the same logic, but for better understanding, we summarized the concepts [20] needed for the reading of model in Fig. 1.
As we identified the tasks, some of them required resources. In particular, we were able to link tasks found in the Design Patterns [8] to components reusing the React JS [3] code. This is the case, for instance, for the task "Create a composition of inputs" that refines the goal "Have the inputs of the services rendered". The "Create a composition of inputs" is operationalized by the component React DOM as per the React JS library [3]. This relation is in the i* model (Fig. 1) as a Needed by relationship. Other resources came from our project artifacts [5], e.g., a topic modeling.
After carrying out the previous steps, we elaborated an i* model of reactivity (Fig. 1), which we propose as the main contribution of this work. As can be seen, the collaborative work performed in section 4, was developed for the agent Reactive System JS. Later, we retake our work on reengineering the ecommerce application, as such, we modeled the actor User and the agent AppWeb with its goals. Finally, we tested the validity of the agent Reactive System JS by finding the dependences among the ecommerce actors and the operationalizations identified for the React JS library agent.
In this model most of the relationships are of the "help" type, which it was influenced on what is indicated in the Reactive Manifesto "we want systems that are Responsive, Resilient, Elastic and Message Driven. We call these Reactive Systems" [7]. As we worked in a consensus of models, we couldn't update relations, such as adding a hurt relation, or new qualities that came up in the meetings we had to identify operationalizations such as the tasks. It is important to note that some of the resources Needed By tasks inside the React JS boundary, are our own artifacts, we use them to verify if we meet the React JS NFRs.
Comparing with other works in reactivity, we can say that this work is novel in explicit the NFRs proposed by reactive libraries such as React JS [3], Angular [21], Vue JS [22]. For the objectives we set in this work, O1: "React as an NFR can be operationalized by using React JS." we found through our process in section 4 that different sources of information can be complemented to identify NFRs with its operationalizations (tasks). For the objective O2: "Organize NFRs and Operationalizations existing in sources of information related to Reactivity using an intentional modeling.", we found that i* helped us to model different tasks or resources as a means to achieve the React NFRs. Finally, for the objective O3: "Create dependency relationships between the Reactive capabilities of React JS and the actor's responsibilities identified for the e-commerce application", we show in Figure 1, that we were able to create strategic dependencies (SD) between the actors' responsibilities of the e-commerce application we modeled and the React JS agent.
It is worth nothing that this model can be reused for the ones interested in understand the reactive paradigm of programming frameworks such as React JS, Angular, and Vue, and the ones dealing with the ecommerce domain and that they can also find the NFRs that can be meet.
The model produced complies with the notation rules specified for i* version 2.0 [23] and using the tool piStar [24].
Despite the positive results, we found our model is initial as it has mostly help-type contribution relationships, none of the seven points of view identified another type of contribution; we believe that this is due to the need for more time to analyze the sources of information or experience with the React Framework to determine negative impacts.
A threat to the validity of the model we had mitigated is that, for each author model, we asked in meetings to present evidence of the traces to the sources of information used.
We plan the development of a new project, in order to enrich the task and goals needed to meet the Reactivity qualities identified.
We thank our colleagues Luis Flores Aquino, Rosmel Deza Condori and Elizon Carcausto Mamani, for providing us with their material and their comments whenever we request. We also thank Professors Roxana Quintanilla Portugal and Julio Cesar Sampaio do Prado Leite for their guidance and their enthusiasm in carrying out this article.