Agent Oriented Software Engineering

for Multimedia Systems’ Development

An Experimental Case Study

Alma M. G

omez-Rodr

ıguez, Juan Carlos Gonz

alez-Moreno, David Ramos-Valc

arcel and

Francisco Javier Rodriguez-Martinez

Dept. de Inform

atica, University of Vigo, Ed. Polit

ecnico D-401, Campus As Lagoas, Ourense E-32004, Spain

Keywords:

Multimedia Systems, Development Process, Agent Oriented Software Engineering(AOSE), INGENIAS

Methodology, Development Tools.

Abstract:

Multimedia systems, and in particular games, have special characteristics that make the process of obtaining

system requirements very difﬁcult. In most cases, an important work of codiﬁcation is needed in order to obtain

a prototype that can be analyzed by the customer and make requirements elicitation easier. This paper proposes

a way of facilitating the process and obtaining a prototype in a short development time. Our proposal is based

in the combined use of a well-known methodology for the construction of Multimedia Systems and Alice, and

follows an Agent Oriented Software Engineering approach. The work introduces the process proposed as well

as a tool that provides support for such process. Besides, a case study shows the application of the process

and the tool to a simple example. From this example, the suitability of Agent Oriented Software Engineering

approach and the proposed process for game prototype development is concluded.

1 INTRODUCTION

Nowadays, multimedia systems have a growing rele-

vance among all the computer-based systems. Almost

any device, from computers to smartphones or tablets,

introduces multimedia components in the applications

that they run (Songers et al., 2001). Besides, Multi-

media developments are complex because they imply

a multidisciplinary team, which must include: physi-

cist because the system incorporates capabilities such

as GPS, gyroscope . . . , mathematicians, graphic de-

signers, musicians, scriptwriters, and, obviously, soft-

ware engineers (Ramos-Valc

arcel et al., 2011).

Among the multimedia systems, games constitute

the most complex system to construct. The reason is

that they incorporate all the multimedia characteris-

tics, as well as, other aspects, such as: deﬁning the

character’s behavior and describing the interactions

(among game characters or between them and the en-

vironment) (Masuch and Rueger, 2005; Capra et al.,

2005; Moreno-Ger et al., 2009).

Despite the importance of multimedia develop-

ments, there is not a public methodology or process

devoted to multimedia development. Although there

are multimedia private companies with productive de-

velopment processes, they are not public because of

the competitive advantage provided.

The special characteristics of multimedia systems

(in particular games, which have characters with a

behavior and sometimes a certain degree of intelli-

gence) make them suitable for applying the agent con-

cept. Agent Oriented Software Engineering (AOSE)

has proof its capability for deﬁnition of complex dis-

tributed systems, where different agents cooperate to

achieve certain goals. Moreover, a previous work

(Ramos-Valc

arcel, 2011) has shown the correspon-

dence between AOSE concepts and game concepts;

for instance agent concept relates to game character,

agent tasks to object functionalities, etc.

In AOSE, many methodologies have been pro-

posed for systems development (Pav

on and G

omez-

Sanz, 2003; Cuesta et al., 2002; Cossentino and

Sabatucci, 2004; Sturm et al., 2003). Among them,

INGENIAS methodology has been selected attending

two basic reasons. The ﬁrst reason is that the differ-

ent models and elements provided by the methodol-

ogy were very suitable for multimedia modeling, as

it has been introduced in previous works (Fuentes-

Fern

andez et al., 2010; G

omez-Rodr

ıguez et al.,

2011). The second reason is that the methodology

provides a tool that supports the development, called

INGENIAS Development Kit (IDK) (Pav

on et al.,

M. Gómez-Rodríguez A., Carlos González-Moreno J., Ramos-Varcárcel D. and Javier Rodriguez-Martinez F..

Agent Oriented Software Engineering for Multimedia Systems’ Development - An Experimental Case Study.

DOI: 10.5220/0003998700850094

In Proceedings of the 7th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE-2012), pages 85-94

ISBN: 978-989-8565-13-6

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

2005). This tool generates automatically code from

the models deﬁned using it, so it can be used as an

initial version of the system to be developed.

Nevertheless, games are very intensive in anima-

tion, so a tool that show how actors behave is needed.

Moreover, the producer of a game expects to see a

storyboard explaining the general idea of the game in

order to take the decision of producing it. Nowadays

there are works that automatically generate an ani-

mated storyboard from a system description that uses

Natural Language (Ma, 2006; Kevin Glass, 2008;

Bola

no-Rodr

ıguez et al., 2011).

Our approach is different, since it generates the

animated storyboard from software engineering mod-

els. From these models, a particular tool, the Interac-

tive StoryBoard Generator (ISBGen), obtains the sys-

tem description using XML. This XML documents

are used as inputs for Alice (Group, 1995; Cooper

et al., 2000), that visualizes these descriptions and

provides them with 3D animation.

Finally, the utility of our approach is proved by

using the development process proposed and ISBGen

in a simple game development.

The remainder of the paper is organized as fol-

lows. Next section introduces the technologies used

in this work, as well as, the relationships among them.

Then, section 3 describes the ISBGen tool, which au-

tomatically generates the multimedia prototype. Sec-

tion 4 broaches the development process for a system

constructed following an AOSE approach and using

the INGENIAS meta-models and the proposed tools.

In the following section, this process is applied to a

case study that shows the results obtained. The paper

ends with the conclusions and future work.

2 TECHNOLOGIES IMPLIED

2.1 INGENIAS and IDK

INGENIAS (Pav

on et al., 2005) is a methodology

created for the development of Multi-Agent Systems

(MAS). Originally the purpose of INGENIAS was

the deﬁnition of a speciﬁc methodology for MAS de-

velopment by integrating results from research in the

area of agent technology, and from traditional Soft-

ware Engineering Methodologies. The methodology

covers analysis and design of MAS, and it is intended

for general use, with no restrictions on application do-

main (G

omez-Sanz and Fuentes, 2002). INGENIAS

is based on the deﬁnition of a set of meta-models

which describe the elements necessary to specify and

get a MAS from ﬁve viewpoints: agent (deﬁnition,

control and management of agent mental state), inter-

actions, organization, environment, and goals/tasks.

The meta-models proposed cover the whole life cycle

and capture different views of the system. In the latest

years, these meta-models have demonstrated their ca-

pability and maturity as supporting speciﬁcation for

the development of MAS (Pav

on and G

omez-Sanz,

2003).

The methodology can deﬁne either hardware or

software agents, and has been applied in the cre-

ation of systems in several engineering ﬁelds, such

as holonic manufacturing systems (Botti and Giret,

2008), multisensor surveillance systems (Pav

on et al.,

2007), knowledge management systems (Soto et al.,

2006), business workﬂow deﬁnition (Hidalgo et al.,

2007), simple games (Pav

on and G

omez-Sanz, 2003)

and Product-Line Engineering environments (Cuesta

et al., 2007).

From the very beginning, INGENIAS methodol-

ogy provides a supporting CASE tool called IDK.

This tool facilitates the construction of the different

meta-models deﬁned in the methodology and gener-

ates code from those deﬁnitions, or at least, code tem-

plates.

Recently the INGENIAS Agent Framework (IAF)

has been proposed taking into account the experi-

ence in application of the methodology during several

years enabling a full model driven development. This

means that, following the guidelines of the IAF, an

experienced developer can focus most of his/her ef-

fort in specifying the system, and so, a great part of

the implementation is converted in a matter of trans-

forming automatically the speciﬁcation into code.

2.2 Alice

Alice (Group, 1995; Conway et al., 2000; Cooper

et al., 2000) is a programming environment which

facilitates the creation of animations where a virtual

world is populated with 3D objects (e.g., people, an-

imals, vehicles . . . ). The tool is available freely and

allows to create animated movies and simple video

games. The tool has an interactive interface, where

the user can drag and drop graphic tiles to create a

program and allows to immediately see how the ani-

mation programs run.

Alice has a huge library of predeﬁned 3D objects.

It includes static and dynamic objects which have a

graphical aspect and, for dynamic ones, a predeﬁned

behavior. This characteristic makes it very suitable

for making a prototype, because, in some cases, the

developer only has to choose what object to include

in the animation.

Other important advantage of Alice is that it fol-

ENASE2012-7thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

Table 1: Correspondence methodological and Alice con-

cepts.

INGENIAS ALICE

Agent Object

Roles Function activation/deactivation

Goals Problems to solve

Task Methods

Interaction Functions

Use Cases Scene Deﬁnition

lows an educative approach. This means that the

tool is user-friendly, what makes easier introducing

changes in the animation. This characteristic is very

interesting in this case, because it facilitates changes

in the prototype and the feedback to INGENIAS mod-

els.

The tool uses Java and C# in its implementation

and stores the deﬁnitions using XML documents. As

stated before, the data structures of both INGENIAS

and Alice are based on XML, so that the integration

of them is easier.

Moreover, a direct correspondence between the

concepts used in the methodology and in Alice has

been established in (Ramos-Valc

arcel, 2011). These

conceptual relationships constitute the formal basis

for automatic generation of the storyboard. Table 1

reﬂects such correspondences.

3 ISBGen

This paper presents the tool ISBGen, which pro-

vides a 3D interactive storyboard automatic genera-

tion from the elements of the meta-models deﬁned

using IDK. ISBGen is one of the contributions of this

work and constitutes an important tool to be used in

the process of multimedia storyboard generation, as it

will be shown in next section.

Figure 1 shows IDK with the ISBGen option. The

central opened window shows the dialogue that ap-

pears when generating the storyboard from the meta-

model deﬁnitions.

The tool facilitates the automatic production of the

Alice ﬁle (with extension .a2w) that contains the sto-

ryboard in the suitable format. ISBGen translates the

meta-models to an XML ﬁle that will be used as input

in Alice. The use of XML provides a great versatility

for adapting the tool, if new characteristics appear in

the models or the tools (IDK and Alice).

Figure 1: ISBGen integrated in IDK.

4 PROCESS OF DEVELOPMENT:

FROM THE META-MODELS TO

THE PROTOTYPE

Traditional game developments usually share two

phases: pre-production and production. The ﬁrst one

includes the preliminary works oriented to deﬁne the

basic characteristics of the game and to propose solu-

tions to the most relevant functionalities. The phase

of production will obtain the ﬁnal product, developing

in detail the sequences deﬁned previously.

Habitually, in pre-production phase, the scripwrit-

ers explain the basic idea using a storyboard which

is evaluated by the responsibles of the project. The

speciﬁcations are given after studying the script or

storyboard that graphic designers make. From both

resources, script and storyboard, a ﬁrst prototype of

the product can be modeled and an animated sequence

is generated . This provides a good simulation of the

ﬁnal sequences to be developed and constitutes a nat-

ural way for the customer (producer, director, etc.) of

verifying the model built.

Our development process covers the pre-

production phase and has as main aim the automatic

generation of the storyboard. This process is based on

the use of AOSE techniques adapted to multimedia

systems, and on the utilization of ISBGen that

produces fast simulation of the multimedia project at

animation level (Storyboard Interactive). At a high

level of abstraction, the process consists of the cyclic

application of the following steps:

1. The elements (object, tasks, goals, etc.) which

constitute the system are deﬁned using INGE-

NIAS meta-models.

2. Using Alice, the graphical part of the elements

AgentOrientedSoftwareEngineeringforMultimediaSystems'Development-AnExperimentalCaseStudy

Figure 2: Prototype generation process.

(characters and objects in the scenery) is included.

This object can be taken directly from Alice li-

brary or adapted from the available ones.

3. The ISBGen tool is used to generate in an auto-

matic way the prototype.

4. The prototype is revised with the customer, the

improvements are noted down and the process

starts again from the ﬁrst step. The changes only

imply to redeﬁne the meta-models.

Figure 2 shows a single iteration of the process

previously described.

Starting from a model constructed using IDK, an

animated sequence, which constitutes a rapid interac-

tive prototype that can be evaluated by the customer,

is obtained. Also, the pre-production team can ana-

lyze the results, corroborate the implementation work

that has been carried out and repair the deﬁciencies or

optimize the features and animations.

Using this process, it is possible to make available

for the customer the idea that the scriptwriter has in

mind, but starring with supporting actors (whose cost

is signiﬁcantly lower than protagonists). The proto-

type developed is a ﬁrst test, that facilitates the study

of all possible technical and graphics solutions to be

applied in the ﬁnal sequences. Moreover, the proto-

type permits to identify not obvious features and con-

tributes to detect errors and problems that may appear

in the future implementation.

The big advantage of this process is that after this

ﬁrst model done in the analysis phase, a sketch of

the system and the possible animated sequences that

the script creates can be presented to the customer.

Moreover, the feedback provided by him can be in-

corporated directly to the meta-models to improve the

scene.

As it has been said before, the process is quick,

because, the graphical part of most objects is obtained

from Alice library. If it is the case that there is not a

suitable object in Alice for a particular element, the

graphical part must be modeled in that moment. Nev-

ertheless, the Alice objects can be adapted, if needed.

The process obtains as output a static model,

which locates the elements inside the scene and de-

ﬁnes what parameters should be modeled. This means

establishing a scenery (a location) and natural compo-

nents of the environment by default. These choices

should reﬂect aspects such as the natural elements

that interact with the environment: trees, plants,

rivers,wind, rain . . . , or the lighting and its different

types (radial, environment, parallel, etc.).

These elements are considered part of the environ-

ment and, as happens in virtual worlds like Second

Life (Kumar et al., 2008; Rymaszewski, 2007) and

OpenSim (Childers, 2009; Fishwick, 2009), should

have their own predeﬁned attributes. Sometimes, the

user should be able to act on such elements, but, in

other moments, it is much more interesting that the

elements have a random behavior, so that, the user

can understand how they interact with the new world

(like in some sites of virtual worlds).

The main aim of this part of the process is to ﬁx

the meta-model elements that are necessary to repre-

sent a multimedia scene and the other elements that

are present on the scene but have not a relevant be-

havior. The agent paradigm provides an enormous

potential to model these elements with undeﬁned be-

havior, that perform the role of extras. The use of

intelligent agents allows deﬁning their behavior inde-

pendently. Once this behavior has been deﬁned, new

not anticipated situations may appear from the inter-

action among agents, and these situations can be iden-

tiﬁed before interfering with the relevant ones.

ENASE2012-7thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

Figure 3: Use case model.

5 CASE STUDY

The system to be modeled as a basic example is a

dialogue between two characters (named Merlin and

Grandmother) who discuss how to give each other a

particular object. The following section explains in

detail and step by step the results that can be achieved

using the process previously described and the intro-

duced tools (Alice, IDK and ISBGen).

5.1 Structure and Use Cases Models

The initial step of this process will be to deﬁne the

project structure, that is, the number of scenes/shots

that compose the whole system. For the case study,

the dialog is composed of a single scene that, in turn,

is divided in several shots (in the example of Figure 3

three shots are shown).

Next, a use case diagram must be modeled. Al-

though this kind of diagram is not used in INGE-

NIAS, we consider that it is of great utility in this

moment of development. The diagram introduces the

scenes which form part of the project and veriﬁes the

integrity of the structure previously deﬁned. Figure 3

presents the use case diagram for the case study. The

diagram shows a system with a scene consisting on

three shots, but the example we are dealing with will

be focused only in the ﬁrst shot.

From this diagram, the ISBGen tool creates in Al-

ice the objects deﬁned in the diagram. Each use case

corresponds to a shot and the tool introduces a num-

ber when generating the Alice object. These numbers

indicate the order in which the use cases are going to

be played. For instance, the model contained in Fig-

ure 3 will generate two objects in Alice: shot1 and

shot11. Shot1 refers to ”Scene 1”, while shot11 cor-

responds to the ”shot1.1” of INGENIAS model that is

part of ”Scene1”’ (see the image in the central bottom

part of Figure 4).

Figure 4: General organization model.

5.2 Organization Model

Following with the deﬁnition of the prototype, next

step is deﬁning the Organization Model, which de-

scribes the groups of agents, the functionality and the

restrictions imposed on the agents. Before starting

this diagram it is important to know the actors who

interact with the system, their roles and, if the actors

play different roles, how this roles will be grouped.

In Figure 4, the Organization Model of the case

study is presented. The system consists of two groups

of agents: static and dynamic agent. The agents be-

longing to the dynamic group are characterized by

their capability to attend user interactions, while those

of the static group do not require user intervention, so

that they are completely autonomous, and act follow-

ing their established goals.

This model has a direct correspondence with the

3D world modeled in INGENIAS and automatically

generated by the tool, which can be seen in bottom

part of Figure 4. ISBGen will generate, both the Mer-

lin and the Grandmother agents from the diagram to

Alice code. So, adding another agent to the virtual

world would be as simple as including him in the or-

ganizational model and link him to a group of agents.

Following the process previously deﬁned, the next

step is to deﬁne another Organization Diagram. In

this case, the diagram details each of the shots associ-

ated to a particular scene. For instance, in the diagram

of Figure 5, the interaction between agents that play

the roles dynamic and help that fulﬁl the tasks Request

Information and Provide Clues.

From this model, the communication between the

two actors that play the roles dynamic and help can

be extracted. The dynamic role selects the charac-

ter to which it makes the request for information and,

then the other role, through the establishment of a di-

alogue, provides the requested information. This dia-

AgentOrientedSoftwareEngineeringforMultimediaSystems'Development-AnExperimentalCaseStudy

Figure 5: Organization model for Shot 1.1.

logue makes that both roles achieve their established

goals. The elements of this diagram are used to deter-

mine which tasks are involved in the interactions that

occur during the execution of the system.

ISBGen does not use this diagram for code gener-

ation, sice since the tasks deﬁnition is performed later,

and the information provided by this diagram is just

illustrative for the developer. For this reason, this step

can be skipped and it is only recommended to deﬁne

these diagrams in large systems where this extra in-

formation can be useful.

5.3 Tasks and Goals Model

Next phase consists in specifying the order in which

the goals must be completed by agents. It is manda-

tory to take such decision before starting the execu-

tion of the system, and it is made through the deﬁni-

tion of Tasks and Goals Model. The Tasks and Goals

Model represents the relationships between goals, so

that the order in which they must be achieved can be

deduced. Moreover, the model may be used to break

down the goals in the particular tasks that must be

done to fulﬁl them. In the case study, the Tasks and

Goals model has a sole goal: to dialogue, so that, the

diagram is not showed here.

Task and Goals Model is very relevant in this pro-

cess because, the hierarchical structure of the system

is completed using the information that it contains.

The methods and functions responsible for managing

the lists of basic and secondary goals are automati-

cally built by ISBGen.

From all the properties available in Alice, we

have choose the most suitable ones for deﬁning agent

characteristics. In particular, ﬁgure 6 reﬂects in Al-

ice the list of goals, methods, functions and proper-

ties associated with the case study. The properties

panel (Properties) of the object world (the root of the

project) -top left image- is an ordered list of the main

goals of the system called GoalHierarchy. It also con-

tains the objects that reference the current, the next

Figure 6: Correspondences Alice - Task and goal model.

and the previous shot. In the methods panel (Meth-

ods) -upper right image- the methods for operating on

the goals list and for modifying the current shot are

shown. The bottom left panel is functions and con-

tains the methods needed to perform operations on

agents, objects, shots and goals. Finally, the bottom

right panel displays the properties of the object prin-

cipal, that is,the main attributes of the main character,

the list of objects and the list of goals, among others.

5.4 Agent Model

Next diagrams to be constructed are based on the

Agent Model. An Agent Model must be done for

each agent in the system. The model will show the

capabilities and goals of each of the actors. The ca-

pabilities are represented by tasks, and each task must

have an associated goal that must be achieved after ex-

ecution. Summarizing, the agent model allows a de-

tailed description of existing agents in the multimedia

system.

An example of this kind of model is shown in Fig-

ure 7. From the deﬁnition of Agent Models, ISBGen

generate the data related to the agent, its tasks and

goals, the methods, and the list of goals to be met,

which will be used in Alice. The ﬁgure reﬂects all the

previous attributes for the main character of the case

study. Each new feature of the 3D character of the

system must be speciﬁed in the corresponding Agent

Model as a task and, also, the goal accomplished by

the task must be speciﬁed. For instance, to make an

actor capable to move, in the Agent Model an agent

with the tasks move and the goal walk must be de-

ﬁned. Once the information is used by ISBGen for

generating the character, this will be reﬂected in the

3D world as a new method of the character of Alice,

ENASE2012-7thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

Figure 7: Agent model.

symbolizing the actor.

The bottom part of Figure 7 contain the proper-

ties, the methods and the functions for the main char-

acter of the case study, in particular the one called

Merlinho. The properties panel represented contains

the list of objects in the system, the ordered lists of

goals and the role played by the agent selected. The

second image -lower left- panel shows the object’s

methods, that is, the basic methods of the dynamic

character, the movements and all the functionalities

speciﬁed in the Tasks and Goal Model for the agents

and tasks. The last image, bottom right, shows the

functions panel, where the exchanges between the el-

ements and the environment are shown. These func-

tions represent the units of interaction described in the

Interaction Model.

5.5 Interaction Model

To complete the example of case study, it is neces-

sary to use the Interaction Model. All the informa-

tion exchanges that occur between two or more ac-

tors in the system should be reﬂected as interactions.

This diagram represents the information exchanges,

breaks down the actions of each interaction and spec-

iﬁes what is sent, and who is the sender and the re-

ceiver.

Figure 8 shows the model that deﬁnes the dialogue

between the two agents, that is the core of the system.

The bottom part of the ﬁgure introduces the ALICE

deﬁnitions associated with the interaction units of the

model. Each interaction unit appears in ALICE as

Figure 8: Interaction model.

Figure 9: Task and goal model.

a function associated with the agent that initiates the

interaction.

5.6 Environment Model

The inclusion of events in the 3D world is done

through the Environment Model, by identifying dif-

ferent internal applications that can be used and

shared by the actors.

Finally, it will be necessary to describe in detail

each of the tasks in the system using again Tasks and

Goals Models. In these models the inputs and out-

puts that occur during the execution of a task and what

are the initiators of such events should be described.

The example in Figure 9 contains the description of

the task Provide clues initiated by receiving certain

information, called RequiredInformation. This task

produces other task GaveInformation, which is used

in the interaction, to complete the objective Provide

clues. In addition, the task changes the mental status

of the agent responsible for the task.

After modeling the environment, as stated before,

an initial review with the customer is carried out. This

AgentOrientedSoftwareEngineeringforMultimediaSystems'Development-AnExperimentalCaseStudy

approach, though simple, allows to discuss with the

customer this ﬁrst prototype of the ﬁnal product.

Any change to this prototype, represents a very

small cost because the system is still in the very early

stages of development. So that, this does not signify

a cost beyond the predictions and is part of the pro-

cess of product development. The customer can im-

mediately see this ﬁrst draft and conﬁrm or change the

speciﬁcation of the generated prototype . Thus, the

interaction developer/customer becomes really efﬁ-

cient, resulting in rapid prototypes that conform to the

pattern expected. Attending the customer changes,

a process redesign, involving product improvement

through optimization of the results of the prototype,

is followed. With all this, a rapid deﬁnition of the ex-

pected product, which may be brought to the stage of

implementation without risks, is obtained.

6 CONCLUSIONS

In the ﬁrst steps of a multimedia project a high-level

prototype makes easier the task of obtaining and val-

idating the basic system’s functionalities. The pro-

totype makes available to the user an overview of the

multimedia product, and facilitates the feedback. This

increases the efﬁciency in the pre-production process,

because all the changes needed are made at initial

stages of development: unnecessary sequences can

be eliminated or others are discovered. Moreover,

the obtained models have more meaningful elements

whose implementation is partially automated thanks

to the tools offered. The use of ISBGen to obtain in

an automatic way the storyboard from those deﬁni-

tions substantially reduces the time and costs of pre-

production.

The use of a well-deﬁned process supported by

several tools introduces a certain degree of formaliza-

tion in multimedia development, which usually lacks

a formal process of software speciﬁcation. In addi-

tion, the use of agent paradigm is very valuable, as the

concept of role, associated to a particular agent behav-

ior, enhances the creation of intelligent autonomous

behaviors that can discover new situations, not de-

ﬁned a priori, that may occur in the scenes. The use of

ALICE, the modeling elements provided by the tool,

as well as their by default behavior, makes it much

easier to ﬁnd objects that adapt to a particular situa-

tion to model.

Using the case study presented, it can be con-

cluded that modeling a multimedia system is feasible

using Agent Oriented Software Engineering. The use

of INGENIAS methodology is not specially relevant,

and in the future, other methodologies will be used.

We consider this is feasible, because the concepts and

elements between different methodologies coincide,

and the process proposed can be applied in the same

way.

The case study has identiﬁed some limitations of

the methodology for being used in this kind of devel-

opments. For instance, INGENIAS introduces many

modeling elements that are not needed for multimedia

deﬁnitions (like the sequence Model or the BDI men-

tal state). Due to this, in the future, we plan to pose

a new methodological proposal that overcomes such

limitations. In addition, a new IDK proﬁle for mul-

timedia systems will be deﬁned, which incorporates

the proposed changes .

Despite the satisfactory results of ISBGen tool,

several improvements are intended to be made in the

future, in order to extend its functionalities. In partic-

ular, an interesting issue will be to incorporate the ca-

pability of selecting the graphical aspect of the agents.

At the moment, the tool automatically assigns an Al-

ice character for each of the agents in the system. In

the future, the user will be able to choose for each

agent its character from the ones available in Alice

library.

The process proposed in this paper follows a

top-down approach. Nevertheless, once the story-

board is obtained and presented to customer, it suffers

changes. Offering a mechanism to automatically in-

corporate those changes to meta-models deﬁnitions,

providing some kind of reengineering process, is, at

the moment, under study.

Finally, we have the intention of integrate

the NPL4INGENIAS tool (Gonzalez-Moreno

and Vazquez-Lopez, 2008; G

omez-Rodr

ıguez

et al., 2011) in the process of development.

NPL4INGENIAS is a tool that obtains the sys-

tem requirements form its description in Natural

Language. The requirements obtained are docu-

mented using the INGENIAS meta-models, this

implies that the tool can be easily integrated in the

process deﬁned here and can simplify the obtention

of a ﬁrst model of the system to construct. A ﬁrst

experiment, which suggest this is possible has been

done in (Bola

no-Rodr

ıguez et al., 2011).

ACKNOWLEDGEMENTS

This work has been supported by the project

Plataforma Tecnoloxica Intelixente de Xestin Avan-

zada para Produtores de Planta Ornamental de Gali-

cia with grant 10MRU007E of Xunta de Galicia.

ENASE2012-7thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering

REFERENCES

Bola

no-Rodr

ıguez, E., Moreno, J. C. G., Ramos-Valc

arcel,

D., and L

opez, L. V. (2011). Using multi-agent sys-

tems to visualize text descriptions. In PAAMS, pages

39–45.

Botti, V. and Giret, A. (2008). ANEMONA: A Multi-

agent Methodology for Holonic Manufacturing Sys-

tems. Springer Series in Advanced Manufacturing.

Capra, M., Radenkovic, M., Benford, S., Oppermann, L.,

Drozd, A., and Flintham, M. (2005). The multimedia

challenges raised by pervasive games. In Proceedings

of the 13th annual ACM international conference on

Multimedia, MULTIMEDIA ’05, pages 89–95, New

York, NY, USA. ACM.

Childers, B. (2009). Run your own virtual reality with open-

sim. Linux J., 2009.

Conway, M., Audia, S., Burnette, T., Cosgrove, D., Chris-

tiansen, K., Deline, R., Durbin, J., Gossweiler, R.,

Koga, S., Long, C., Mallory, B., Miale, S., Monkaitis,

K., Patten, J., Pierce, J., Shochet, J., Staack, D.,

Stearns, B., Stoakley, R., Sturgill, C., Viega, J.,

White, J., Williams, G., and Pausch, R. (2000). Al-

ice: Lessons learned from building a 3d system for

novices.

Cooper, S., Dann, W., and Pausch, R. (2000). Alice: a 3-d

tool for introductory programming concepts. Journal

of Computing Sciences in Colleges, 15(5):107–116.

Cossentino, M. and Sabatucci, L. (2004). Agent System Im-

plementation. Agent-Based Manufacturing and Con-

trol Systems: New Agile Manufacturing Solutions for

Achieving Peak Performance. CRC Press.

Cuesta, P., G

omez, A., Gonz

alez, J., and Rodr

ıguez, F. J.

(2002). The MESMA methodology for agent-oriented

software engineering. In Proceedings of First Interna-

tional Workshop on Practical Applications of Agents

and Multiagent Systems (IWPAAMS’2002), pages 87–

98.

Cuesta, P., G

omez-Rodr

ıguez, A., and Gonz

alez-Moreno,

J. C. (2007). Agent oriented software engineering. In

Whitestein Series in Software Agent Technologies and

Autonomic Computing, pages 1–31. Springer.

Fishwick, P. (2009). An introduction to opensimulator and

virtual environment agent-based applications. In Sim-

ulation Conference (WSC), Proceedings of the 2009

Winter, pages 177 –183.

Fuentes-Fern

andez, R., no, I. G.-M., G

omez-Rodr

ıguez,

A. M., and Gonz

alez-Moreno, J. C. (2010). A

technique fordeﬁning agent-oriented engineering pro-

cesses with tool support. Engineering Applications of

Artiﬁcial Intelligence, ‘23(3):432– 444.

omez-Rodr

ıguez, A., Gonz

alez-Moreno, J. C., Ramos-

Valc

arcel, D., and V

azquez-L

opez, L. (2011). Model-

ing serious games using aose methodologies. In Intel-

ligent Systems Design and Applications (ISDA), 2011

11th International Conference on, pages 53 –58.

omez-Sanz, J. J. and Fuentes, R. (2002). Agent ori-

ented software engineering with ingenias. In Fourth

Iberoamerican Workshop on Multi-Agent Systems (Ib-

eragents’2002), a workshop of IBERAMIA’2002, the

VIII Iberoamerican Conference on Artiﬁcial Intelli-

gence.

Gonzalez-Moreno, J. C. and Vazquez-Lopez, L. (2008). De-

sign of multiagent system architecture. In Ieee, editor,

IEEE International Workshop on Engineering Seman-

tic Agent Systems, pages 565–568, Turku (Finlandia).

IEEE.

Group, U. U. I. (1995). Alice: Rapid prototyping for virtual

reality. IEEE Computer Graphics and Applications,

15:8–11.

Hidalgo, A., Gomez-Sanz, J., and Mestras, J. (2007). Work-

ﬂow Modelling with INGENIAS methodology. In

5th IEEE International Conference on Industrial In-

formatics (INDIN’07), volume 2, pages 1103–1108.

Vienna, Austria.

Kevin Glass, S. B. (2008). Automating the creation of 3d

animation from annotated ﬁction text. In IADIS 2008 :

Proceedings of the International Conference on Com-

puter Graphics and Visualization 2008, pages 3–10.

Kumar, S., Chhugani, J., Kim, C., Kim, D., Nguyen, A.,

Dubey, P., Bienia, C., and Kim, Y. (2008). Second life

and the new generation of virtual worlds. Computer,

41(9):46 –53.

Ma, M. (2006). Automatic conversion of natural language

to 3D animation. PhD thesis, University of Ulster,

Derry, Ireland.

Masuch, M. and Rueger, M. (2005). Challenges in col-

laborative game design developing learning environ-

ments for creating games. In Proceedings of the

Third International Conference on Creating, Connect-

ing and Collaborating through Computing, pages 67–

74, Washington, DC, USA. IEEE Computer Society.

Moreno-Ger, P., Fuentes-Fern

andez, R., Sierra-Rodr

ıguez,

J.-L., and Fern

andez-Manj

on, B. (2009). Model-

checking for adventure videogames. Information and

Software Technology, 51(3):564 – 580.

Pav

on, J. and G

omez-Sanz, J. (2003). Agent Oriented Soft-

ware Engineering with INGENIAS. Multi-Agent Sys-

tems and Applications III, 2691:394–403.

Pav

on, J., G

omez-Sanz, J. J., Fern

andez-Caballero, A., and

Valencia-Jim

enez, J. J. (2007). Development of intel-

ligent multisensor surveillance systems with agents.

Robotics and Autonomous Systems, 55(12):892–903.

Pav

on, J., G

omez-Sanz, J. J., and Fuentes-Fern

andez, R.

(2005). The INGENIAS Methodology and Tools, arti-

cle IX, pages 236–276. Idea Group Publishing.

Ramos-Valc

arcel, D. (2011). Ingenier

ıa de software orien-

tada a agentes en el modelado de sistemas multimedia

(in spanish). PhD thesis, Universidad de Vigo. Depar-

tamento de Inform

atica. Escola Superior de Enxe

ner

ıa

Inform

atica.

Ramos-Valc

arcel, D., Fajardo-Toro, C., and de la

Pena Ojea, F. (2011). Multimedia smart process

(msp). In Information Systems and Technologies

(CISTI), 2011 6th Iberian Conference on, volume 1,

pages 320–325.

Rymaszewski, M. (2007). Second life : the ofﬁcial guide.

John Wileyy.

Songers, A., Diekmann, J., and Karet, D. (2001).

Animation-based construction schedule review. Con-

AgentOrientedSoftwareEngineeringforMultimediaSystems'Development-AnExperimentalCaseStudy

struction Innovation: Information, Process, Manage-

ment, Colorado.

Soto, J. P., Vizcaino, A., Portillo, J., and Piattini, M. (2006).

Modelling a Knowledge Management System Archi-

tecture with INGENIAS Methodology. In 15th Inter-

national Conference on Computing (CIC’06), pages

167–173. Mexico City, Mexico.

Sturm, A., Dori, D., and Shehory, O. (2003). Single-model

method for specifying multi-agent systems. In AA-

MAS, pages 121–128. ACM.

ENASE2012-7thInternationalConferenceonEvaluationofNovelSoftwareApproachestoSoftwareEngineering