An architecture for dynamic and evolving cooperative software agents

Computer Standards & Interfaces 25 (2003) 261 – 269 www.elsevier.com/locate/csi

An architecture for dynamic and evolving cooperative software agents Patricia Paderewski-Rodrı´guez *, Ma. Jose´ Rodrı´guez-Fortiz, Jose´ Parets-Llorca Departamento de Lenguajes y Sistemas Informa´ticos, ETS Ingenierıá Informa´tica, Universidad de Granada, C/ Periodista Daniel Saucedo Aranda, s/n., 18071 Granada, Spain

Abstract This paper presents an architectural model to construct cooperative and evolutionary agent-based software systems. Here, a software system is defined as one consisting of a set of agents which interact by executing actions and by determining system functionality. Because the agents need intercommunication and coordination, we propose a model that allows this communication between agents and preserves system activity. This coordination model uses a blackboard as the means of communication between the system agents. The system architecture presented is dynamic in the sense that the modelled system can evolve and be adapted to its new functions. To do this, we distinguish two levels in the architecture: the system and the metasystem levels. The system level describes the system’s structure and its functionality, while the meta-system level allows us to effect changes in the system in such a way as to preserve the system’s integrity and restrictions. Modifications at the system level are carried out when the developer interacts at the meta-system level. System users interact only at the system level. D 2002 Elsevier Science B.V. All rights reserved. Keywords: Agent; Blackboard; Cooperative systems; Evolution; Software architecture

1. Introduction A software system can be conceived of as a set of cooperating components, or agents, which carry out actions. An agent [5] is autonomous, independent and always functional if the environment is favourable. Therefore, a system is a set of autonomous agents functioning concurrently. The system may comprise complex tasks usually involving several agents. In this case, it is necessary for the agents to communicate and to cooperate in order to fulfil the task assigned. The * Corresponding author. E-mail addresses: [email protected] (P. Paderewski-Rodrı´guez), [email protected] (M.J. Rodrı´guez-Fortiz), [email protected] (J. Parets-Llorca).

advantages of agent autonomy may, however, be a negative factor for their communication and cooperation. In order to optimise the latter, an appropriate coordination model is necessary, one that is capable of adaptation to possible evolutionary changes in the system, i.e., changes in the structure of the system. During the life of a software system, many circumstances exist that may provoke changes, such as the execution environment, the user conditions or the functionality. The system should be capable of adapting to such changes. To achieve this, we present a dynamic architecture that is adaptable to the environment and to the user’s necessities. The agents that intervene in the coordination and the relationships between them can change, adapting to a new functionality. This paper shows how the agents’ autonomy and

0920-5489/02/$ - see front matter D 2002 Elsevier Science B.V. All rights reserved. doi:10.1016/S0920-5489(02)00097-1

262

P. Paderewski-Rodrı´guez et al. / Computer Standards & Interfaces 25 (2003) 261–269

independence facilitate the evolution and adaptation of the system and the reuse of the agents in the design of a different system. The paper is structured as follows. Section 2 describes the underlying basic architecture in a cooperative agent-based software system and defines the fundamental concepts of the system architecture. Section 3 presents the coordination model used by the agents and its characteristics that allow the system to adapt to changes. We then present the second level of this architecture, which allows us to model the system’s evolution by means of a meta-system. In Section 5, we comment on related work. Finally, we enumerate the main conclusions and comment on future work.

2. Basic architecture From an abstract viewpoint, software architecture involves the description of components from which systems are built, interactions among those components, patterns that guide their composition and constraints on these patterns. In general, a particular system is defined in terms of a collection of components and interactions among those components [15]. In the architecture that we present, the components are agents, actions, preconditions associated with the actions and the functional history of the system (a shared dataspace implemented as a blackboard). The interactions among components are established using a hierarchy of agents, associating preconditions with the actions and defining complex actions. Let us define and comment on the elements of this architecture. A software system is known by the set of actions that are carried out in it, actions which can be carried out simultaneously. The entities that carry out actions in a system are called software agents or simply agents. Therefore, a system is composed of a set of agents which execute actions in a concurrent way. Initially, we are not concerned with how an agent is implemented; this might be a process, a thread or an active object. In order to know if an agent can carry out an action, each action has an associated precondition. Basically, this precondition states a condition on the realisation of previous actions or on the reception of a stimulus, that is, on the confirmation that one or more actions have previously been carried out (occurrences of the execu-

tion of an action) or a stimulus has been received. The stimulus is sent via the system interface with the users or with other agents. A subset of Predicate Temporal Logic (PTL) is used to define the preconditions [6,14]. This logic is used because the knowledge of temporal order relationships and the specification of conditions based on previous states of the system [1,2] is of interest. When a precondition is defined, it is checked to ensure that the integrity of the system is not violated [13]. For this purpose, a list of invariants is established for each system, which must always be satisfied. A new action with its precondition is accepted if this precondition satisfies the system invariants [14]. The blackboard architecture [15] consists of two kinds of components: a central data structure that represents the current state of the system (its history), and a collection of independent components (the agents) that operate on the central data store. The current state of the central data structure is the main trigger for selecting actions that agents will execute. We use a common blackboard in each system that serves as a medium of communication among the agents and maintains a history of what has happened in it from the beginning of its history. Because the blackboard stores the history of the system we term it the System Functional History (SFH). The occurrences of the actions carried out by the agents in the system are stored in this history. If an agent needs some information, it consults the history of the system. This implies that a group of agents are continually checking whether they can carry out actions by consulting the state of the system. This software system architecture is illustrated in Fig. 1.

Fig. 1. Software system architecture.


An agent has the same architecture as that previously described for a software system. This allows us to reuse software systems when their functionality is included in the new one being designed. Therefore, the architecture presented here has a fundamental characteristic: it is hierarchical. The nesting concept is contemplated within the system architecture in such a way as to permit a hierarchy of nested agents. The reason for nesting agents lies in the necessity to carry out complex actions, each comprising various simple actions. When an agent carries out a complex action, it is composed of various simple agents each carrying out the individual actions. The agents which are at the same nesting level communicate with each other through a shared SFH. Each agent has its own SFH, and the agents at the same level share a unique SFH so that they can communicate and cooperate. Fig. 2 shows the structure of an agent (Agent 1), which has two nested agents (Agent 1.1 and Agent 1.2) that in turn contain other nested agents. A complex action is considered executed only when each simple action is concluded (or in certain special cases, aborted). The occurrence of the execution of the complex action is stored in the SFH of the main agent. The nested hierarchy is interesting because a system can, thus, be defined as an independent agent that has nested agents, providing a group of actions at each level. The lowest level in this hierarchy consists of a group of agents that carry out only simple actions. In this way, one system can become part of another simply by incorporating itself as another agent. In the next section, we explain agent cooperation in a more detailed way. To illustrate these concepts, let us consider a simple example, that of a car rental company. In this system, the components are the employees working in the com-

263

pany (agents), the functions they carry out (actions), the preconditions associated with the actions and a history of the occurrences of the actions. In this company, there are three kinds of employees: those that assist the clients, the Employees, those in charge of collecting the services, the Collectors and the Mechanics, who check the cars and buy new ones if necessary. The actions of the Employees are rent (car) and return (car). The Collectors only carry out the action collect (client), while the Mechanics carry out two actions: buy (car) and check (car). Therefore, this system (called Rent-A-Car system) comprises different kinds of agents. There are even agents (the Employees) that carry out the same actions (rent and return) executed in a concurrent but independent way (in the sense that there is no direct communication between the agents). If an agent carries out the action rent, the precondition is that a car should exist and it must be free. This precondition considers the actions that took place before the current time instant in the system, and can be expressed as the following temporal condition: rentðxÞ < wðbuyðxÞandðcheckðxÞSince returnðxÞÞ This means ‘a car x can be rented if previously it has been bought and has been checked since it was returned’. Therefore, three actions intervene in the precondition of the action rent: buy, check and return, actions which are carried out by different agents. Every time an agent, (Employee, Collector or Mechanic) carries out an action, the occurrence of this action is stored in the SFH. For example, if the action rent is carried out, an occurrence is generated for rent, information that is stored in the SFH to indicate that a certain car has been rented. This example contains a hierarchy: the agent Mechanic has two nested agents, the agent Buyer that carries out the action buy and the agent Checker that carries out the action check. Both agents cooperate with each other. For example, the agent Buyer buys depending on the results of the Checker’s actions. If a car is very old, another is bought for the system.

3. Coordination model

Fig. 2. Agent nesting.

An agent-based system is composed of a set of concurrent agents which carry out actions and deter-

264


Fig. 3. Structure of the controller agent.

mine the functionality of the system. These actions can be classified as:

Simple actions: actions carried out by one agent. Complex actions or transactions: a set of ordered actions carried out by a set of agents. A transaction should be atomic, i.e., from the environment point of view, a transaction is a unique action. The agents should be coordinated to carry out complex actions but they do not need explicit knowledge of each other.

The architecture presented in the previous section implies that the agents have no explicit knowledge about other agents. This independence between agents facilitates the evolution and adaptation of the system. To establish how the coordination relationships between agents should be achieved and how the problems arising from such coordination are to be solved, the basic architecture is extended and a new component is added: the Controller agent. This agent performs concurrently with other agents. 3.1. A special agent: the controller

A special agent, called Controller, is introduced to solve these problems. This agent is in charge of providing services to the other agents, namely the evaluation of preconditions and the reception of new action occurrences. The Controller design follows the Precondition Dynamic Notifier (PDN ) design pattern [10]. In addition, this agent guarantees the consistency of the SFH and provides an order to the agent requests. Each agent has its own Controller to manage its own SFH. Fig. 3 shows the structure of the Controller, whose functionality is divided between the PDN and Evaluator agents. It also contains the SFH, which stores the occurrences of actions. The PDN agent stores occurrences of actions and activates agents. The Evaluator agent checks action preconditions and provides an answer to agents’ queries. Next, we will comment how the three problems mentioned above are solved. The first problem, that of concurrent access, is solved by sequencing the read and write operations on the history in order to avoid possible inconsistencies. Fig. 4 shows how any interaction of the agents of the Rent-A-Car system is managed by its own Controller. The coordination between the agents Employee-1, Employee-2, Employee-3, Collector and Mechanic is effected by Controller-1. If the Mechanic is an agent that has nested agents, Buyer and Checker, the coordination between these, if necessary, is managed by Controller-2. The second problem stated above is especially important in the structural evolution of the system. This problem is solved by preventing an agent from testing the preconditions when there are no possibilities of success. In order to accomplish this task, the Con-

The architecture described above presents three main problems: 1. The concurrent access for reading and writing in a central structure, the SFH. 2. The activation of the agents. Because the agents have to test the preconditions of their actions, they are always testing the preconditions, which implies a loss of efficiency. 3. The evaluation of preconditions should be carried out without interference from new actions. When a precondition is being tested, the SFH can be modified.

Fig. 4. Rent-A-Car system.


troller is in charge of activating the test of a precondition only when certain possibilities of success exist. This implies that the Controller has knowledge about the agents, their actions and preconditions, knowledge which changes dynamically as the system evolves. In particular, the PDN agent maintains a set of tables containing information that relates the agents, the actions they may carry out and the occurrences of these actions contained in the preconditions. Fig. 5 shows these tables for the Rent-A-Car system. The first level table lists the agents comprising the System. The second level stores information about the actions for each agent and the third stores information about the actions that appear in the preconditions. The entire precondition of an action is a temporal logical expression that is associated with the agent that carries out the action and must be evaluated by the Evaluator. Although there are different agents of the same kind, each has its own tables that can evolve independently. That is to say, Employee-1 can evolve and have different actions from Employee-2, for instance. When an action occurrence arrives, it should be stored in the SFH, and the Controller checks what agents may be involved (those that have this occurrence in a precondition). The Controller sends and schedules messages to the agents indicating what actions have some probability of execution. In this way, only those agents that have some possibilities of executing an action attempt it and avoid the collapse

265

of the System by preconditions evaluation requests. For example, let us suppose that an occurrence of the action return arrives, the Controller knows that the affected agents are Employee-1, Employee-2 and Employee-3, and for the action rent. Therefore, the PDN agent sends them a message indicating that they can begin the evaluation of the rent precondition. The third problem is solved blocking the SFH while the agent Evaluator is checking a precondition and establishing additional conditions which provide mutual exclusion. This is necessary because if only a car is free for renting only one occurrence of the rent action should be allowed.

4. System evolution During the life of a Software System a lot of circumstances exists which produce changes. The environment of execution, the user conditions or functionality can change. This possibility require an adaptation and evolution of the system, i.e., the addition of a new agent, the deletion of an agent, a change in the cooperation mechanisms. A Software System runs over time. It has an architecture which may be able to change, evolving and maturating over time and during its use. Based on the Theory of Systems [8], the functioning of a System depends on its structure at each moment. In order to adapt, if the structure changes, the functioning changes. In order to manage the evolution, a new level of abstraction is added to the previous architecture presented. Therefore, a two level architecture is considered (see Fig. 6): 1. The first level specifies the architecture of a Software System seen in Sections 2 and 3. 2. The second level specifies the Meta-system. It is in charge of changing the structure and, therefore, the functioning, of the Software System. The developer interacts at this level creating and modifying a Software System, specifying, designing and changing it.

Fig. 5. Information managed by controller 1.

When an user needs a modification in the functioning of a Software System, the developer will be informed and will change the structure of the Software System by means of the Meta-system. A meta-system

266


The objective of the evolutionary actions is to modify the structure of a software system. Both the components (agents, actions, history and preconditions) and the interactions can be changed. The set of evolutionary actions which can be carried out for each element are as follows. 4.1. Agents

Fig. 6. The two-level architecture.

is also a software system but its structure and functioning do not change. The developer uses it as a CASE tool to allow evolutionary actions, creating and modifying the structure of a software system. Because integrity must be maintained during the evolution of the software system, it is not possible to carry out all the desired changes. In order to do this, a list of invariants must be established for each system, and a set of meta-preconditions guarantees these invariants. The meta-preconditions must be specified and associated with the evolutionary actions. These meta-preconditions are also stated in a special predicate temporal logic [14]. Evolutionary actions must satisfy the invariants of the previously established software system. These invariants depend on the general specification of the system and the desired characteristics. For example, an invariant could be: ‘‘the names of the agents of the system must be different’’. An evolutionary action sometimes modifies one agent or action within a system in relation to another agent or action. This can be affected by the change in such way that another evolutionary action has to be carried out to adapt it to the change. The modification must be propagated to ensure the integrity of the whole system. For example, an invariant of the system could be: ‘‘each agent must have at least two nested agents’’. In this case, the evolutionary action ‘‘deleting an agent’’ should propagate the evolutionary action ‘‘nesting with an agent’’. This last action associates the remaining agent to another agent of a cluster in order to maintain the invariant. In order to guarantee coherence and consistency, the evolutionary actions are communicated to the Controller which updates information on the components of the system: agents, actions and preconditions.

Adding, deleting or modifying the agents of the structure. These actions are carried out in a transparent way for the rest of agents comprising the System due to the use of the blackboard and of the nonexplicit communication between the agents. An agent is interested in actions carried out in the system but not in the particular agents who carry them out. When these evolutionary actions are carried out, the Controller of the system (or of the agent) is informed and upgrades their tables to be able to act correctly when the system continues its functioning [10]. When an agent is deleted and the Meta-system accepts this change (the operation does not violate the invariants) the PDN agent of the corresponding Controller modifies the information in their tables. Information that relates an action with action occurrences and stimuli is obtained from a syntactic analysis of the preconditions. Although two agents may have the same behaviour, each agent is unique for the system because each can evolve independently and therefore, each has a different row in the table of agents. The deletion of an agent implies that the actions that it carries out are deleted. This may constitute a problem if no other agent carries out these actions because agents might then be blocked waiting for the occurrence of an action that nobody can carry out. For example, if we delete the agent Employee-3 in the Rent-A-Car system, Employee-1 and Employee-2 can fulfil Employee-3’s actions. On the contrary, if we delete the agent Mechanic, what happens when we try to evaluate the precondition of the action rent? It would be never true if nobody in the system carried out the actions buy and check. The Meta-ystem determines, by means of the invariant list, whether such an evolutionary action is allowed. 4.2. Actions The addition, deletion or modification of the actions that the agents carry out follow the same


patterns as above commented. When an action is deleted, many preconditions may be affected, and in this case, a careful propagation of changes with respect to the invariants should be made. 4.3. Preconditions Adding, deleting or modifying the preconditions implies the need to ensure coherence and consistency. For this purpose, we use the method proposed in Ref. [14], which specifies when these evolutionary actions can be carried out depending on the structure of preconditions. The PDN agent adds or deletes the corresponding rows in the third level of tables.

5. Related work One of the first coordination models (and languages) is known as Linda [3,7]. In this model, a shared dataspace, the tuple space, is used to coordinate and communicate concurrent activities. It also contains a small set of operations which allows the agents access to the tuple space. The model presented in this paper also uses a shared communication medium, the SFH, but it is not a unique one because a hierarchical data multi-space (nested agents) is used. Moreover, the objects stored in the history are more complex [12], than the tuples used in Linda. Linda serves as a point of reference for the development of other coordination models [9]. PoliS [4], is a coordination model that has the same philosophy as Linda, and has many points in common with the model presented here. PoliS is based on multiple tuple spaces and a space is a multi-set of tuples. Agent nesting in our model implies that a global tuple space does not exist, but the tuple space is a multi-set of tuple spaces which are related in a hierarchical way. Actions in PoliS (program tuples) are associated with a preactivation condition (the preconditions in our model) and a postactivation condition (our action occurrences) that modifies the tuple space. The main difference between the two models is that PoliS does not consider the problem of evolution and adaptation. Although the addition and deletion of tuples is possible in PoliS, the dynamic change of the structure of a system is not possible. The content of the tuple space can be changed but these changes are not

267

evaluated to test the integrity of the system. In our model, the structure of a system can be changed in several ways (agents, actions, preconditions) in such a way that the specification of a system is an iterative and evolutionary process of changes whose integrity is guaranteed by means of invariants and meta-preconditions. Moreover, the temporal order in the tuple spaces is not considered in PoliS. This is significant when the time instant of actions determines whether a precondition holds. In this sense, the use of temporal logic allows us to reason about time without needing an explicit representation. A further factor is that in our model the activation of the agents is produced when some possibility of success exists. The agents do not require continuous evaluation of the preconditions. In this sense, the PDN agent operates as an Event Notifier. This kind of Event Notifier is also used in other models, such as JavaSpaces and T Spaces [9]. These models include an Event Notifier per request, while in our case, we have a Controller per tuple space.

6. Conclusions and future work We describe the basic architecture of a cooperative agent-based software system. The necessary communication between the agents collaborating to carry out a common task does not depend on the agents (explicit communication) but is rather carried out by means of a blackboard. The proposed architecture is extended with a new agent, the Controller, responsible for implementing the coordination pattern to allow communication between the agents. The Controller solves the problems related to the activation of the agents and controls the blackboard (history of the occurrences of the actions carried out in the system). We explain how the presented architecture allows the system to evolve, allowing adaptations to the environment. This evolution is carried out by the development team by means of a special software system termed the Meta-system. The Meta-system modifies the structure and functioning of the software system by a set of evolutionary actions. These evolutionary actions allow additions to, deletions of or modifications to the components of the system (agents,

268


actions and preconditions). The Controller maintains information about the system in the form of tables that are updated as the system evolves. The concept of nesting agents is explained; thus, the system comprises a hierarchy of agents, providing a set of actions at each level. The lowest level in this hierarchy is constituted of a set of agents that carry out only simple actions. In the present implementation of the model [11,12], the tables maintained by the Controller are built starting from a simple syntactic analysis of the preconditions expressed in temporal logic. In the near future, we will improve the efficiency of this by means of a detailed study of the logic operators in the preconditions in order to construct the internal tables of the Controller. An optimum evaluation of preconditions is desirable to be able to reduce the number of agents notified when an event happens, since this notification overloads the system. The notified agents should be those that have a high probability of being able to carry out certain actions. Another interesting improvement would be to apply the functionality of this architecture and of the coordination model in distributed systems, with the aim of adapting it to build systems based on mobile agents. Initially, although we have a shared SFH, this should only be visible for the agents at the same nesting level. The internal SFH of a particular agent can be located at any node of a network, together with the agents that need it and with the specific Controller.

Acknowledgements This research is supported by a project— MEIGAS—by the Spanish CICYT (TIC2000-1673C06-04), which is a subproject of the DOLMEN project (TIC2000-1673-C06).

References [1] A. Anaya, M.J. Rodrı´guez, P. Paderewski, J. Parets, Time in the evolution and functionality of information systems, in: M. Toro (Ed.), JIS ’96, Sevilla. (1996) 161 – 170.

[2] A. Anaya, M.J. Rodrı´guez, J. Parets, Representation and management of memory and decision in evolving software systems, in: F. Pichler, R. Moreno Dıáz (Eds.), Computer Aided Systems Theory—EUROCAST’97 Lecture Notes in Computer Science 1333, Berlin, Springer-Verlag, 1997, pp. 71 – 82. [3] N. Carreiro, D. Gelernter, Linda in Context, Communication of ACM 32 (4) (1989) 444 – 458. [4] P. Ciancarini, F. Franze`, C. Mascolo, A coordination model to specify systems including mobile agents, Proceedings of IWSSD9. IEEE Computer Society, 1998, pp. 96 – 105. [5] S. Franklin, A. Graesser, Is it an agent, or just a program? Lectures Notes on Artificial Intelligence, Proceedings of the Third International Workshop on Agent Theories, Architectures, and Languages, 1996. Springer-Verlag, Berlin, Germany, 1997, pp. 21 – 35. [6] D.M. Gabbay, M. Hodkinson, I. Reynolds, Temporal logic, Mathematical Foundations and Computational Aspects, Oxford Logic Guides, vol. 1, Oxford Science Publications, Oxford, England, 1995, p. 28. [7] D. Gelernter, N. Carreiro, Coordination ‘‘languages and their significance’’, Communications of ACM 35 (2) (1992) 97 – 107. [8] J.L. Le Moigne, La Theórie du syste´me geńe´ral. Tho´rie de la modelisation, Paris: Presses Universitaires de France, 1977 – 1983 – 1990. [9] A. Omici, F. Zambonelli, M. Klusch, R. Tolksdorf (Eds.), Coordination of Internet Agents. Models, Technologies, and Applications, Springer-Verlag, Berlin, Germany, 2001. [10] P. Paderewski, J. Parets, An activation pattern for active objects, in: P. Botella, J. Hernandez, F. Saltor (Eds.), JISBD ’99, 1999, pp. 257 – 268. Caceres, Spain. [11] P. Paderewski, J. Parets, A. Anaya, M.J. Rodrı´guez, G. Sańchez, J. Torres, M.V. Hurtado, A software development tool for evolutionary prototyping of information systems, Computers and Computational Engineering in Control Electric and Computer Engineering Series, World Scientific, Greece, 1999, pp. 347 – 352. [12] M.J. Rodrı´guez, J. Parets, P. Paderewski, A. Anaya, M.V. Hurtado, HEDES: a system theory based tool to support evolutionary software systems, in: Lectures Notes in Computer Science, vol. 1798, Springer-Verlag, Berlin, Germany, 2000, pp. 450 – 464. [13] M.J. Rodrı´guez-Fortiz, J. Parets-Llorca, Using predicate temporal logic and coloured Petri nets to specifying integrity restrictions in the structural evolucion, International Symposium on Principles of Software Evolution, ISPSE2000. [14] M.J. Rodrı´guez, Software evolution: a formalisation based on temporal logic and coloured Petri nets (in Spanish), Doctoral thesis, Granada University, 2000. [15] M. Shaw, D. Garlan, Software Architecture, Prentice-Hall, New Jersey, USA, 1996.

P. Paderewski-Rodrı´guez et al. / Computer Standards & Interfaces 25 (2003) 261–269 Mrs. Patricia Paderewski-Rodrı´guez is an Associate Professor in the Departamento de Lenguajes y Sistemas Informa´ticos at the University of Granada (Spain). Her research publications are in the areas of software systems evolution models, cooperative agent-based systems, object-oriented methods, tools and languages.

Dr. Marıá Jose´ Rodrı´guez-Fo´rtiz is an Associate Professor in the Departamento de Lenguajes y Sistemas Informa´ticos at the University of Granada (Spain). Her research publications are in the areas of software systems evolution models, formal methods for specification, object-oriented methods, tools and languages. She received her PhD from the University of Granada. She is a reviewer of Information and Management Journal (North-Holland).

269

Dr. Jose´ Parets-Llorca is a Full Professor in the Departamento de Lenguajes y Sistemas Informa´ticos at the University of Granada (Spain). He is also Research Director of the group on Software Development and Evolution at the same department. He received his PhD from the University of Granada. His project experience and publications have been in the areas of object-oriented development methods and tools, software systems evolution models and applications and evolution paradigms from different disciplines (biology, sociology and psychology).