<strong>Introduction</strong>

Even though the design of agent-based models can be very complex, at its core there is always a set of agents that operate within a certain environment. The nature of agents and their probable actions can differ from model to model, and so can the environment. When developing a complex model, it is possible to split it into relatively independent functional submodels that focus on certain aspects of the bigger problem. These separate parts usually have agents of the same type and sometimes - the same environment, but the properties and actions of the agents are different, and - if existent - external forces have an influence only on the aspects within this submodel, even though it still might have an indirect impact on other submodels as well.

<strong>Traditional Approach</strong>

Using traditional approach, we would have separate teams, and each would implement the conventional structure of the model (Falcone 2019). To illustrate the general setup of the software implementation of an agent-based model (ABM) I present an illustration from the (Masad 2015) that shows on a UML diagram the general structure of the MESA Python framework (Pic. 1). As it is easy to mention, usually ABM is implemented with two classes (Kinny 1996): a <em>model</em> class, that contains a list with agents, properties of the environment and related to them methods, and an <em>agent</em> class (Salamon 2011), that contains corresponding properties and methods.

<img src="http://ras.jes.su/images/publication_images/9237/image1.png" class="image-formula"/> <em>Pic.</em><em> </em><em>1 </em><em>Part of the s</em><em>implified UML diagram of Mesa architecture (</em><em>Masad</em><em> 2015)</em>

In this paper we will not draw the line between agent-oriented programming and object-oriented programming of agent-based models since the implementation seems to be close in terms of architectural approaches. Also we are not going to focus on issues of agents interactions with each other and environment, and therefore, we will not discuss implementation of communication, perception, etc.

To add some clarification, let’s assume that we use sequential model (illustrated on Pic. 2). In this case, a loop within a <em>model</em> calls a method <em>step(</em><em>)</em> every time interval <em>T</em>. This <em>step(</em><em>)</em> method conducts all operations related to environment and contains another loop that iterates agents (or uses any other scheduling option).

If we have two teams that work on two aspects of the same model, we will have two sets of <em>model</em> and <em>agent</em> classes. Each would have its own constructor and there would be two <em>step(</em><em>)</em> methods. So, if we decide to integrate these two models into a single one, we would have to either merge these two sets of classes manually, either create two sets of models and agents and then sequentially or in a parallel manner call them and somehow sync with each other. Both options seem to be quite effort consuming.

<img src="http://ras.jes.su/images/publication_images/9237/image2.jpeg" class="image-formula"/> <em>Pic.</em><em> </em><em>2</em><em> Flowchart scheme of a conventional agent-based model</em>

<strong>Suggested Approach</strong>

What else we can do, is to create a <em>model</em> class that is inherited from existing two and do so for the <em>agent</em> class as it is presented on Pic. 3. (Parunak 2001).

By doing so we would have to call <em>step(</em><em>) </em>from the first<em> model </em>class<em> </em>and then<em> step() </em>from the second, so we would have to change the original naming of at least one method and call them directly. This seems to be better, as we would have only a single set of agents and we don’t need to conduct data synchronization. But the problem is that the more parts we have, the more changes we would have to make. It would be nicer to reduce our integration efforts.

<strong>Implementation</strong>

We can make all the teams use the same <em>Model</em> and <em>Agent</em> templates that utilize the same structure and have some equally named methods. So, we expect each team to create modules of suggested structure that will allow them to be used in a single model without additional integration procedures. In the program, this will be implemented by iteration of parents’ classes and calling methods of the same name. The implementation of such approach in Python is presented at Pic. 4. In this sample code three modules (<em>demo</em>, <em>labor</em> and <em>user</em>) are loaded. Each of them contains two classes: <em>Model</em> and <em>Agent</em>, the <em>Model</em> in each has a <em>step(</em><em>agents)</em> method that receives a list of agents. After the modules are loaded the <em>ExtendedModel</em> and the <em>ExtendedAgent</em> classes are created based on a generic <em>Model</em> and <em>Agent</em> classes and by inheriting from loaded classes.

<p><img class="image-formula" src="http://ras.jes.su/images/publication_images/9237/image4.png" alt="" /> <em>Pic.</em><em> </em><em>4</em><em> Code </em><em>sample</em><em> of several modules being loaded and merged into a single model.</em></p>

Generic <em>Model</em> class contains a simple method that calls for methods of its parent classes and provides them with a list of <em>ExtendedAgent</em> class objects. This method is presented in Pic. 5.

<img src="http://ras.jes.su/images/publication_images/9237/image5.png" class="image-formula"/> <em>Pic.</em><em> </em><em>5</em><em> Method that calls for parents</em><em>’</em><em> classes’ methods and provides them with a list of </em><em>ExtendedAgent</em><em> class objects.</em>

<strong>Opportunities</strong><strong>,</strong><strong> limitations</strong><strong> and notes</strong>

Such approach allows to integrate easily several models into a single one. Obviously, there are significant limitations that come with this easiness. First, all classes must have agents of the same nature, otherwise it will all make no sense. Secondly, all parties should be cautious about using same variables and therefore additional costs on interactions and synchronization of the development process have to be considered.

As a side note it is worth mentioning the way to implement agents’ replication. The <em>Extended</em><em>Agent</em> class has to be transferred to the <em>ExtendedModel</em> as a parameter so it is possible to either create new <em>ExtendedAgent</em> objects within the model, or - if we want greater realism - to transfer it further to the <em>Agent</em> within particular module during iterations over the parents’ classes. For example, within the <em>Demographic</em> module it would be possible to let <em>Demographic</em> agents have kids that are <em>ExtendedAgents</em> just like their parents are. Without this transfer there would be no way to create agents that inherit all properties of all <em>Agent</em> classes of all modules loaded.

<strong>Conclusion</strong>

All in all, it seems that such approach allows to speed up the development of complex agent-based models with significant simplification of the integration process. However, this comes at a cost of potential overlapping functionality that can disrupt an integrated model operation in an obscure manner.