4. Evolution of Agent-Based Simulation Models 37
4.2. Network-Based Model for Monitoring Software Quality
4.2.1. Growth Model Depending on Productivity
To model the growth trend of a software project only two agents are required. Firstly, software entities that represent the software system under simulation. Secondly, the developers actively influence the growth of the project with their contribution to the project under simulation. The ABM to simulate the growth of software projects is depicted in Figure 4.4.
4. Evolution of Agent-Based Simulation Models 42 As software entities, we consider files due to the fact that we only need the number of files for growth statements according to [89]. A File has only a reference to the developer who created it as attribute. Furthermore, a file can be considered as a passive agent because its state depends only on the development work of the developers in this model.
The Developeris the active agent because its development work adds,deletes, and updates files. This contribution makes the project evolve over time and for growth considerations we can omit the updates performed by the developers. A detailed description of the developers contribution model and required parameters can be found in Section 4.2.1.1.
- pCommit : real developdevelop
use use
create create
Figure 4.4.: Agent-based simulation model to replicate growth trends of software projects.
The SimulationContext is the initial class when executing the simulation model.
It creates a given number of developers at the start of the simulation and contains project-specific parameters such as the maximum project size and the number of rounds to simulate. Furthermore, the context knows all instantiated agents, passive as well as active ones, as it is indicated by the list SimulationContext.agents.
The simulation is round-based and one round in the simulation represents one day in real life. Every turn each developer has the opportunity to work. If the agent works, the project will be further developed through its contribution. This is also the basic principle of all further simulation models. The closer the project size approaches the given maximum size, the fewer new files are created by the work of the developers. This, together with the assumption that stronger growth is expected at the beginning of the project, leads to the typical growth [90] of a software project as depicted in Figure 4.5a. These parameters are gathered by mining open source repositories than described in Section 5.2.
As mentioned in Section 3.2.1, we can have several growth trends. To config-ure the simulation when mined parameters are not suitable to simulate growth
43 4.2. Network-Based Model for Monitoring Software Quality trends like the super-linear one depicted in Figure 4.5c theAdjustableParameters can be used. For this purpose, the project is divided into two parts. The first part takes AdjustableParameters.initialRounds and the last one takes the rest of the projects runtime. As a responsible parameter for growth, the mined developers contribution can be adjusted for the first part with the pa-rameter AdjustableParameters.initialBoostFactor and for the last part with AdjustableParameters.boostFactor. These parameters allow us to simulate a more realistic growth trend as with mined average parameters only.
To illustrate different growth trends, we plot the growth in the number of files for the three open source projects commons-io1, gora2, and zookeeper3 and the results are presented in Figure 4.5. According to [91] all growth trends can be fitted with a linear function.
(a) Growth of zookeeper. (b) Growth of commons-io. (c) Growth of gora.
Figure 4.5.: Different growth trends of real software projects.
Since the contribution behavior of the developers are the driving factor for this model, as well as for further models concerning the evolution of software processes, this part will be described in detail in the next section.
4.2.1.1. Developer Contribution Behavior
Due to the round-based nature of the simulation, at the beginning of each round, it must be decided whether a developer is working or not. Working means, that the developer applies a commit. For this, we assume that the commits of one developer are uniformly distributed. This decision depends on the probability Developer.pCommit. The number of commits, each instance of the typeDeveloper has applied, is stored in the propertyDeveloper.commitCount.
When a developer applies a commit in the current round, the scope of the work still needs to be determined. Therefore, the number of files that are added and deleted in the commit are required. For this purpose, we assume that the number of file
1https://github.com/apache/commons-io
2https://github.com/apache/gora
3https://github.com/apache/zookeeper
4. Evolution of Agent-Based Simulation Models 44 changes follows a geometric distribution. We are using that form of the geometric distribution in which the number of failures until the first success is modeled as shown in Equation (4.1). This means that zero is allowed.
P(X=n) = (1−p)n·p forn={0,1,2,3, . . .} (4.1) For the simulation, this can be interpreted as being a success from a developer’s point of view if it has nothing to do and thus zero files have to be updated. All actions a developer can perform are modeled the same way, but for growth trend analysis we only consider delete and add actions while the number of updated files is omitted.
These both properties of a developer, i.e., the probability to apply a commit in the current round and the number of files to add or delete in one commit are enough to model the growth trend of software projects. However, the simulated set of files does not represent any features of the actual software system except size. An extension of the model will show in the next sections how other aspects of the software system can be simulated. This allows extended research questions, which can be answered by the model.