-A major nightmare of software developers is having clients claiming the delivered software is not what they expected. Developers make an extensive use of prototypes to prevent such situations to occur. However, the role of simulations have not been studied enough. If an agent based simulation is intended, not all existing agent oriented methodologies are capable of it. It requires code generation capabilities, round-trip features, and components with predefined behaviors. This work introduces the ability of the INGENIAS Agent Framework to simulate MAS specifications and how this can be useful for for agile development of agent-based applications.
A software development needs to verify the system under construction satisfies a client needs. Requirements engineering has contributed strongly to the solution by guaranteing the requirements are properly captured and processed. Software development processes have been modified to include the ideas of incremental development (segmenting the system functionality into coherent pieces and ordering them so that their sequential/paralell realisation leads to the final system), iterations (miniprojects focusing on the development of a concrete piece of functionality of the application). Expected products from this development process include several types of documents aiming to communicate with the client and tell them what is being done; and acceptance tests, to ensure the behavior of the application is the one expected. Despite these avances, prototyping seems to be a recurrent option.
Prototypes [
In this scenario, agent technology has been recognised
as an affordable mean for producing prototypes and define
simulations [
In this aspect, INGENIAS [
This paper discusses how INGENIAS can make use of the simulation concept in order to develop a software system. The discussion bases in the features provided by the INGENIAS Agent Framework, which is introduced in section II. The way this software can be used to simulate is introduced in section III. The introduction of the case study concerns to section IV. The INGENIAS solution to the case study is made in section V. The simulation made in this case study itself is introduced in section VI and evaluated in section VII. The related works are presented in section VIII. Finally, section IX introduces the conclusions.
IAF stands for the INGENIAS Agent Framework. It is a framework developed along several years that enables a full model driven development. This means that a developer can focus most of its effort in specifying the system, converting a great deal of the implementation in a matter of transforming automatically the specification into code. This IAF permits to combine the classic approach for coding applications with modern techniques of automatic code generation. The resulting system is almost fully operational, reducing the amount of work of the developer in an relevant degree. Each produced MAS works over the JADE platform. Hence, additional tools existing for this framework can be applied as well.
A MAS in the IAF is constructed over the JADE platform. the system-to-be are included as well, reusing directly preThe MAS can be distributed along one or several containers dedefined behaviors from the IAF. in one or many computers. To enable this feature, the IAF has means of declaring different deployment configurations. A. Simulating the internals of the application
The running MAS will be connected to several non-agent The IAF provides built-in predefined behaviors which can applications providing the basic services. Hence, if the MAS be used to simulate parts of the application. They are introhas to interact with a user, there will be GUIs producing duced following: events according to user actions, and defining actuators for agents. These GUIs will be specified as applications at the specification level.
An important feature of the IAF is the relevance of interactions, which are considered first class citizens during specification and coding. An interaction in runtime is called a conversation. The interactions according to the IAF have the main purpose of transferrring information from one agent to another. This information transfer is ruled by timeouts and initiation/colaboration conditions. Also, interactions can be aborted due to failures in the communication or simply because an agent did not answer within the timeout. Finally, the software code realising interactions consider cases where there may be several actors of the same time, i.e., supports the deliver of information to several recipients and the reception of the answer from several agents at the task level.
Tasks are important as well. An agent chooses to schedule a task for execution because the agent wants to attain a pursued goal. The tasks influence in the mental state by removing/adding information, starting conversations with other agents, or modify already existing conversations. Tasks support cardinality attributes associated to the inputs, so a task can use as input all instances of a certain information type or just a few.
Custom deployments permit the developer to define which types of agents will be used and what individual mental state will have during the start-up. This feature allows the developer to define different configurations of the system so that the developer can observe the behavior of the MAS under such conditions.
Testing is a recent addition to the IAF. A developer can define at the specification level what tests will be performed and to what configuration of MAS will be applied. The detailed definition of the test has to be handcrafted, though there are some software libraries that make this work easier.
Task Raw simulation. The developer defines no specific code for tasks, assuming the default behavior of tasks in the IAF. This behavior consists in consuming/reading the information declared as input and producing all the outputs declared in the specification. All produced instances of information entities are empty. This means that if an information entity has attributes, its instances will see these attributes exist, though they have empty values.
Also, when a task creates an instance of an interaction, i.e., a conversation, the collaborators will be chosen randomly among existing valid ones (a valid agent type or a valid agent role according to the interaction definition).
If one collaborator is defined as having cardinality greater than one, then multiple agents satisfying the requirements from the concrete interaction specification are chosen and incorporated automatically.
Application Raw simulation. The applications are
wrappers for non-agent software. The default code produced
for such instances of applications does nothing.
Nevertheless, if the specification declared a certain event has to be
produced from the application, then the IAF generates a
GUI from which the user can trigger the generation of an
instance of the expected event. This new instance would
be incorporated automatically into the mental state of the
agent owning the application. If the specification declares
an application type is owned by certain agent type, then
an instance of an application can be accesible only to an
instance of the agent type or to multiple instances of the
agent type (this is implemented by means of a singleton
pattern [
Interaction Raw simulation. For each agent capable of initiating a conversation, the IAF generates a basic GUI that can trigger this conversation without having a task launching it. The conversation may not progress if the corresponding information that should be delivered/received does not exist. Therefore, a simulation of the interactions must be accompanied with a specialized deployment where the initial mental state of involed agents satisfies the requirements of the interaction at the specification level.
AGENT FRAMEWORK
In general, there are two approaches for simulation using the IAF: simulating the environment or simulating the environment and the application. In the first, MAS infrastructure is provided in order to represent different elements of the target runtime environment. Therefore, there is external software (the one recently developed and whose behavior is to be verified) and the environment built with a MAS. The external software would be docked to the MAS based environment by means of application entities. In the second, not only the elements of the application environment are provided, but parts of Using these pre-defined behaviors, the developer models the internals of the application using an agent oriented methodology, like INGENIAS, and proceeds to observe how the resulting MAS behave.
The simulation can get closer to the actual intended software by customizing more the behavior of the elements: Adding custom code to the tasks in the MAS. Instead of the default behavior (consuming input entities and creating new ones in the output), a developer can code more concrete behavior, like using existing APIs from applications to perform actions or detail which collaborators a conversation will have. This new code is inserted into a code component entity and used to replace the code in the generated task. These changes are maintable throught he use of the code uploader module of the INGENIAS Development Kit, which migrates changes made to tasks into existing code components in the specification. Adding initialization/shutdown code for applications. This code permits to properly construct/shutdown the application knowing during creation/shutdown time which agent will be assigned to it. This way, an application acquires a reference to its agent or agents.
Modifying the API of the application code and providing
a body to the methods. An application can be coded
adhoc for a concrete development or act as mediator [
The degree of customization is a decision of the developer. The resulting MAS can become the intented system or remain as a proof that the MAS specification is valid for the problem. In the first, case, the specification and the customization of the generated code would progress towards the final system. In the second case, the developers would decide to realize the specification into a different agent platform or just reuse the acquired knowledge to be used within another methodology (agent oriented or not).
The IAF recognises automatically generated code, manually maintained code, and a hybrid mixture of both. All of them exist into separated folders. Hence, a developer can work safely in the src folder, creating clasess regularly; delete safely the content of gensrc folder knowing that it can be completely generated from the specification; or customize the content of permsrc folder knowing that changes made will not be overwritten by sucessive code generation requests.
Once key elements to be simulated are identified, a developer can represent them as agents or as applications. It is an agent when its behavior of the simulated entity can be captured with goals and tasks and the execution of the corresponding tasks corresponds to the achievement of goals. It is an application in other case. Being an application means an API is offered and that this API can be used within the tasks of the agent. Optionally, the application is expected to produce events in order to notify agents of changes. As explained in the previous section, these events can be asserted within a single or multiple owners.
The external software (software which already exists before
the current MAS is developed) is wrapped into applications.
Generated code for applications will act as a mediator [
Most likely, there will be agents representing the different types of users in the system, which could be humans or not. A developer will define a certain role capturing the generic behavior expected from that user. This behavior is supposed to be assumed by a agent or specialised by another role. Assuming there is a role with a task X having as input an entity type Y, the specialization can happen as follows. First, an agent can define a task XX having as input the entity Y. This will cause tasks XX will be executed instead of tasks X. Second, a new role extending the original role can be defined. This new role, can define a task XXX having as input the entity Y. This will cause tasks XXX are executed before the task X. In both cases, when task XX or XXX is executed, they, probably, will remove entity Y from the mental state, aborting this way any possible execution of previously scheduled X tasks.
With these two ways of capturing behaviors, a developer can create populations of users with varying behaviors. The resulting agents will perform actions over the existing applications, which are supposed to be connected to the software system currently under execution.
Once the MAS is defined, it is time to perform different runs of the system. The user can inspect visually the results by means of the IAF default GUI. Nevertheless, it is convenient to make use of a more exhaustive and objective analysis by means of studying the system logs. The INGENIAS Agent Framework produces logs with the produced events in a system run, so that they can be inspected and accounted later on. Registered events are:
as well as the id of the agent, are provided A new piece of information is added/removed to/from the agent mental state. The id and type of the entity as well as the id of the agent are provided.
A task has been executed. The id and type of the task, as well as the id of the agent, are provided
expected inputs that were missing, as well as the id of the agent, are provided A conversation has been started. The id of the conversation, the interaction type, collaborators, and the id of the launcher agent, are provided An agent decides to participate into an requested conversation. The id of the conversation, the interaction type, collaborators, and the id of the launcher agent, are provided A message has been delivered. The id of the message, its content, sender and receivers are provided
Each event is marked with a timestamp (24 hour format and milliseconds format) obtained from the same hardware clock. Therefore, this timestamp should not be used as a reference to compare logs produced into different physical machines.
By properly interpreting each task, the developer can produce graphics similar to those frequently found in conventional simulations. For example, a task Y is designed to peform a payment through paypal in ebay after a succesfull auction. By accounting the times this task was executed, and using timestaps, it can be generated a graphic of the number of finished auctions through a determined period of time.
Technological advances are increasing with time. The volume of scientic publications patents, research projects, technology news and related international standards of technology is in continuous increase. This makes available to researchers, R+D organizations, and industry in general, a huge amount of information to analyze for their projects and strategies. Technology Watch Systems are involved in processing of all information tech- nology environment to extract knowledge, such as identifying trends and changes. This case study focuses on the management of quality of information sources within a Technology Watch System.
Technological watch is a tool used wihtin Competitive
Intelligence. Competitive Intelligence is the legal obtention,
analysis, distribution of information about a competitive
environment, including strong and weak points as well as the
intentions of competitors [
In an organization dedicated to R+D, clients of a Technological Watch are research groups. These researchers, generally, have already located relevant information sources to be watched. Therefore, researchers are a potential suppliers of information sources. If the system was feeded with bad quality information sources, the system would supply results with noise causing the analyses to be inadequate or wrong. This problem suggests the system should not accept all suggested information sources. In fact, giving more relevance to those researchers investing effort in providing good information sources would potentially increase the quality of the produced results. Similarly, controlling more bad suggestors allows to keep the quality degree.
The development of Technological Watch system follows
recommendations from the UNE 166006:2006 EX [
Therefore, this case study to what extent reputation and trust models can be integrated in a Technological Watch System. The question is how such functionality can be integrated, i.e., are new components needed? is it enough with modifying the responsibilities of existing components?
This evaluation has required building a prototype dealing with three basic scenarios corresponding to the use case Manage quality of information sources by means of reputation and trust models:
A low quality information source proposal made by a collaborator with low reputation in general A high quality information source proposal made by a collaborator with high reputation in general A low quality information source proposal made by a collaborator agent subject of bad reputation on behalf a supervisor agent which has witnessed past requests from the same agent.
The development made focuses in the first scenario.
In the long term, the developed MAS aims to discover what kind of agents are required in order to have a population representative of a real scenario. Also, As it is now, it serves to experiment with the necessary protocols for integrating a trust model in the information sources management mechanisms.
As figure 1 shows, there are four groups of agents in the organization responsible of technological watch services.
Collaborators. They are agents which propose new information sources. These agents can be a human operator representative or, directly, an agent that does not require a human operator.
Supervisors. They are resposible of deciding how to evaluate proposals from the collaborators.The evaluation itself is performed by agents belonging to the Test Team. Test Team. They assign a quality value to an information source prior to its incorporation into the system. They do this by pretending the source is already incorporated and starting to use it with some predefined queries. Also they can request human expert evaluations.
Operations Team. They watch accepted information sources and other technological watch services. There are agents within this group who are in charge of inspecting accepted information sources. They maintain updated information about the quality of the sources. This evaluation is used later to compute the trust degree of collaborators.
The MAS developed uses the REGRET trust model [
Focusing on a SupervisorRole, this role has as goal keeping the system with high quality information sources. The capabilities of this role are expressed as tasks (fig. 2): ProcessReceivedProposalTask. The agent can process proposal from collaborators.
AddSourceIntoSystemTask. The agent can add accepted information source into the system. This task also includes the request of quality inspection for the accepted information source.
RequestAlphaQualityInspectionTask. The agent can request alpha quality inspection to inspectors. “Alpha quality inspection” means making a quality inspection without adding the information source into the system to be watched.
ProcessAlphaQualityInspectionResultTask. The agent can process the results of alpha quality inspections. ProcessQualityInspectionResultTask. The agent can process the results of quality inspections.
Task ProcessReceivedProposalTask (fig. 3) is activated when the fact SourceProposed is found. The SourceProposed fact comes in the proposal message of the PerformProposal conversation. This task makes decisions about what filters apply to the proposal as follows:
Reject the proposal because the collaborator has attempted too much to add information sources with low quality. The task produces the RejectedProposal fact to be sent as response in the reject-proposal speaking act of the PerformProposal conversation.
Request an alpha quality inspection for the information source in order to obtain quality information in some criterias. It is because the supervisor doesn’t trust in the collaborator about the quality (in some criterias) of information sources which he usually proposes. The objetive behind is to apply the selected filters, that is, If the information source has the quality value (in a specific criteria) less than the minimum quality value permited (in the specific criteria), then reject the proposal. Otherwise, accept the proposal. The task produces the SourceToProve fact to indicate the request.
Request the adding of the information source into the system to be watched. The proposal is accepted because the supervisor trust in the collaborator. The task produces the SourceToProcess fact to indicate the request.
The TrustInformations fact has the information about trusting of all collaborators who have made proposal to the supervisor.
After developing this prototype, a greater knowledge of the problem has been acquired. Using INGENIAS, generic information exchanges were depicted, detailing the information exchanged and having some wired code dealing with its transformation.
The development time was reduced to a minimum, one person for one weeks at full time (eight hours a day). Taking into account that the actual Technological Watch system has been developed for two years, this seems a reasonable price for having an accurate specification of the problem. Also, incorporating the produced system as an add on to the real system remains a possibility.
The simulation of the environment was straightforward to produce. Since the protocols were already established, it was known what information the system was expecting from the users. So, defining GUI agents interfacing with real human operators or agents pretending to act directly with the system was easy. From here, deciding the kind of agents to deploy and their specific features, was a matter of depicting an ingenias deployment entity.
The degree of reusability is not known yet. The model was concluded recently and it is currently under the evaluation of other partners in the project. Should the specification be accepted, the ideas woud be incorporated into production, modifying the current Technological Watch system being used.
Figure 5 shows the GUI of the developed system where The current state of art of agent oriented software
engineerdifferent actions can be triggered to run the basic scenarios. ing methodologies shows only a little number of
methodoloThe log corresponds to these sequence of actions. First, the gies permitting to produce directly code and perform the kind
Collaborator makes a proposal of a information source with of simulations made with INGENIAS. Methodologies like
regular quality.The Supervisor #0 applies the filter, it’s mean, MaSE [
The simulation of the system leads to a log of several customization of the produced code is not as effective as in
megabytes of information. By filtering the content, and fo- INGENIAS. A developer in INGENIAS will find several tools
cusing in the production of AcceptedProposal entities, Reject- to synchronize the produced code with the specification. In
edProposal entities, and SourceProposal, it is straightforward MaSE, this possibility does not exist.
to obtain a list of events which tell when such entities are ADELFE [
PASSIM [
In the work introduced in this paper, the simulation generation is automatic and its content can concern the whole application or only its environment. Also, INGENIAS provides means to integrate with external applications, where PASSIM does not.
INGENIAS simulation agents base on the BDI paradigm and are coded that way. In PASSIM, the coding corresponds to the statechart formalism. Like in SeSAm.
Prototyping and simulations are two ways of clarifying system requirements and experimenting with different approaches in a domain problem. Prototypes are expendable and simulations, depending on the support tool, are expendable as well. A simulation performed with SeSAm, for instance, cannot be used as a final product to be delivered to end users. Hence, an approach permitting prototyping, creating simulations, and reduce costs in producing both, would be welcome.
INGENIAS can provide such services. In INGENIAS, with the aid of the INGENIAS Development Kit and the INGENIAS Agent Framework, it is possible to experiment different configurations of a MAS investing little effort. Also, it is possible to create artificial environments where there are simulated human operators or external agents interacting with the developed system. The result of the experimentation is a MAS specification capturing the requirements of the client, whose interpretation can be inspected visually by the client; and a MAS obtained automatically from the specification, which can be used as prototype or as final system, depending on the needs of the development.
Modelling and Simulation of Complex Social Systems (SiCoSSys), supported by Spanish Council for Science and Innovation, with grant TIN2008-06464-C03-01. Also, we acknowledge the funding from the Programa de Creaci o´n y Consolidaci o´n de Grupos de Investigaci o´n UCM-Banco Santander for the group number 921354 (GRASIA group).