Multiagent Systems Mdlg Ctl Pgmg Simuls Applns F Alkhateeb

Multiagent Systems Mdlg Ctl Pgmg Simuls Applns F
Alkhateeb download
https://ebookbell.com/product/multiagent-systems-mdlg-ctl-pgmg-
simuls-applns-f-alkhateeb-4114470
Explore and download more ebooks at ebookbell.com

Here are some recommended products that we believe you will be
interested in. You can click the link to download.
Multiagent Systems 19th European Conference Eumas 2022 Dsseldorf
Germany September 1416 2022 Proceedings Dorothea Baumeister
https://ebookbell.com/product/multiagent-systems-19th-european-
conference-eumas-2022-dsseldorf-germany-
september-1416-2022-proceedings-dorothea-baumeister-48714458
Multiagent Systems And Agreement Technologies 17th European Conference
Eumas 2020 And 7th International Conference At 2020 Thessaloniki
Greece September 1415 2020 Revised Selected Papers Nick Bassiliades
https://ebookbell.com/product/multiagent-systems-and-agreement-
technologies-17th-european-conference-eumas-2020-and-7th-
international-conference-at-2020-thessaloniki-greece-
september-1415-2020-revised-selected-papers-nick-bassiliades-50334450
Multiagent Systems Simulation And Applications Adelinde M Uhrmacher
https://ebookbell.com/product/multiagent-systems-simulation-and-
applications-adelinde-m-uhrmacher-2256370
Multiagent Systems For Healthcare Simulation And Modeling Applications
For System Improvement Premier Reference Source 1st Edition Raman
Paranjape
https://ebookbell.com/product/multiagent-systems-for-healthcare-
simulation-and-modeling-applications-for-system-improvement-premier-
reference-source-1st-edition-raman-paranjape-2454860

Multiagent Systems For Society 8th Pacific Rim International Workshop
On Multiagents Prima 2005 Kuala Lumpur Malaysia September 2628 2005
Revised Selected Papers 1st Edition Hideyuki Nakashima Auth
https://ebookbell.com/product/multiagent-systems-for-society-8th-
pacific-rim-international-workshop-on-multiagents-prima-2005-kuala-
lumpur-malaysia-september-2628-2005-revised-selected-papers-1st-
edition-hideyuki-nakashima-auth-2536322
Multiagent Systems And Applications 9th Eccai Advanced Course Acai
2001 And Agent Links 3rd European Agent Systems Summer School Easss
2001 Prague Czech Republic July 213 2001 Selected Tutorial Papers Les
Gasser Auth
https://ebookbell.com/product/multiagent-systems-and-applications-9th-
eccai-advanced-course-acai-2001-and-agent-links-3rd-european-agent-
systems-summer-school-easss-2001-prague-czech-republic-
july-213-2001-selected-tutorial-papers-les-gasser-auth-4142688
Multiagent Systems And Applications Iv 4th International Central And
Eastern European Conference On Multiagent Systems Ceemas 2005 Budapest
Hungary September 15 17 2005 Proceedings 1st Edition Giovanni Rimassa
https://ebookbell.com/product/multiagent-systems-and-applications-
iv-4th-international-central-and-eastern-european-conference-on-
multiagent-systems-ceemas-2005-budapest-hungary-
september-15-17-2005-proceedings-1st-edition-giovanni-rimassa-4239156
Multiagent Systems And Applications V 5th International Central And
Eastern European Conference On Multiagent Systems Ceemas 2007 Leipzig
Germany September 2527 2007 Proceedings 1st Edition Smaine Mazouzi
https://ebookbell.com/product/multiagent-systems-and-
applications-v-5th-international-central-and-eastern-european-
conference-on-multiagent-systems-ceemas-2007-leipzig-germany-
september-2527-2007-proceedings-1st-edition-smaine-mazouzi-4239878
Multi Agent Systems Technologies And Applications Towards
Humancentered Shibakali Gupta
https://ebookbell.com/product/multi-agent-systems-technologies-and-
applications-towards-humancentered-shibakali-gupta-42952484

MULTIͳAGENT SYSTEMS ͳ
MODELING, CONTROL,
PROGRAMMING,
SIMULATIONS AND
APPLICATIONS
Edited by Faisal Alkhateeb,
Eslam Al Maghayreh and Iyad Abu Doush

Multi-Agent Systems - Modeling, Control,
Programming, Simulations and Applications
Edited by Faisal Alkhateeb, Eslam Al Maghayreh and Iyad Abu Doush
Published by InTech
Janeza Trdine 9, 51000 Rijeka, Croatia
Copyright © 2011 InTech
All chapters are Open Access articles distributed under the Creative Commons
Non Commercial Share Alike Attribution 3.0 license, which permits to copy,
distribute, transmit, and adapt the work in any medium, so long as the original
work is properly cited. After this work has been published by InTech, authors
have the right to republish it, in whole or part, in any publication of which they
are the author, and to make other personal use of the work. Any republication,
referencing or personal use of the work must explicitly identify the original source.
Statements and opinions expressed in the chapters are these of the individual contributors
and not necessarily those of the editors or publisher. No responsibility is accepted
for the accuracy of information contained in the published articles. The publisher
assumes no responsibility for any damage or injury to persons or property arising out
of the use of any materials, instructions, methods or ideas contained in the book.
Publishing Process Manager Katarina Lovrecic
Technical Editor Teodora Smiljanic
Cover Designer Martina Sirotic
Image Copyright Lilya, 2010. Used under license from Shutterstock.com
First published March, 2011
Printed in India
A free online edition of this book is available at www.intechopen.com
Additional hard copies can be obtained from orders@intechweb.org
Multi-Agent Systems - Modeling, Control, Programming, Simulations and Applications,
Edited by Faisal Alkhateeb, Eslam Al Maghayreh and Iyad Abu Doush
p. cm.
ISBN 978-953-307-174-9

Part 1
Chapter 1
Chapter 2
Chapter 3
Chapter 4
Chapter 5
Part 2
Chapter 6
Chapter 7
Preface IX
Multi-Agent Systems Modeling 1
Requirements Modeling for Multi-Agent Systems 3
Lorena Rodriguez, Emilio Insfran and Luca Cernuzzi
A Multi-Agent System Architecture
for Sensor Networks 23
María Guijarro, Rubén Fuentes-Fernández and Gonzalo Pajares
Modeling Artificial Life Through
Multi-Agent Based Simulation 41
Terry Lima Ruas, Maria das Graças Bruno Marietto,
André Filipe de Moraes Batista, Robson dos Santos França,
Alexandre Heideker, Emerson Aguiar Noronha
and Fábio Aragão da Silva
Development of Multi-Agent Control
Systems using UML/SysML 67
Iskra Antonova and Idilia Batchkova
Stackelberg Solutions to Noncooperative
Two-Level Nonlinear Programming Problems
through Evolutionary Multi-Agent Systems 91
Masatoshi Sakawa, Hideki Katagiri and Takeshi Matsui
Control, Negotiation, Reasoning, Tracking
and Networking on Agents Environments 101
Convergence and Collision
Avoidance in Formation Control: A Survey
of the Artificial Potential Functions Approach 103
Eduardo G. Hernández-Martínez and Eduardo Aranda-Bricaire
Negotiation in Multi-Agent Environments 127
Dorin Militaru
Contents

Contents
VI
Reasoning about Resource-Sensitive Multi-Agents 143
Norihiro Kamide
Fast Visual Tracking of Mobile Agents 159
Andelko Katalenic, Ivica Draganjac, Alan Mutka and Stjepan Bogdan
How Computer Networks Can Become Smart 177
Ricardo Bagnasco and Joan Serrat
Autonomous Decentralized Voltage Profile
Control Method in Future Distribution
Network using Distributed Generators 193
Takao Tsuji, Tsutomu Oyama, Takuhei Hashiguchi, Tadahiro Goda,
Kenji Horiuchi, Seiji Tange, Takao Shinji and Shinsuke Tsujita
Multi Agent Systems combined with Semantic Technologies
for Automated Negotiation in Virtual Enterprises 221
Koppensteiner Gottfried, Merdan Munir, Lepuschitz Wilfried,
Moser Thomas and Reinprecht Constantin
Intelligent Collaboration Environment
in Multi-Agent System Enabling Software
Dynamic Integration and Adaptive Evolving 243
Qingshan Li, Lili Guo, Xiangqian Zhai and Baoye Xue
The Fusion of Fuzzy Temporal Plans:
Managing Uncertainty and Time
in Decentralized Command and Control Systems 271
Mohamad K. Allouche and Jean Berger
Robust Consensus of Multi-agent Systems
with Bounded Disturbances 297
Lin Wang and Zhixin Liu
Multi-Agent Systems Programming 315
Principles of Agent-Oriented Programming 317
André Filipe de Moraes Batista, Maria das Graças Bruno Marietto,
Wagner Tanaka Botelho, Guiou Kobayashi,
Brunno dos Passos Alves, Sidney de Castro and Terry Lima Ruas
Multi-Agent Systems Simulations and Applications 343
Multimedia Authorship Tool for the Teaching
of Foreign Languages and Distance Learning
in a Multiagent Environment 345
Adroaldo Guimarães Rossetti, Almir dos Santos Albuquerque,
Vasco Pinto da Silva Filho and Rogério Cid Bastos
Chapter 8
Chapter 9
Chapter 10
Chapter 11
Chapter 12
Chapter 13
Chapter 14
Chapter 15
Part 3
Chapter 16
Part 4
Chapter 17

Contents VII
Image Processing on MR Brain Images
Using Social Spiders 363
Moussa Richard, Beurton-Aimar Marie and Desbarats Pascal
Towards Implementing an Intelligent System
for Securing and Monitoring using Agents 383
Faisal Alkhateeb, Zain Al-Abdeen Al-Fakhry, Eslam Al Maghayreh,
Ahmad T. Al-Taani and Shadi Aljawarneh
Pro-Active Multi-Agent System in Virtual Education 393
Victoriya Repka, Vyacheslav Grebenyuk and Katheryna Kliushnyk
Simulating a Land Development Planning
Process through Agent-Based Modeling 415
Michael Kieser and Danielle J. Marceau
Autonomous and Intelligent Mobile Systems
based on Multi-Agent Systems 451
Adil Sayouti, Hicham Medromi and Fouad Moutaouakil
Multi-agent Systems for Industrial Applications:
Design, Development, and Challenges 469
Atalla F. Sayda
Bio-Inspired Multi-Agent Technology
for Industrial Applications 495
Petr Skobelev
Chapter 18
Chapter 19
Chapter 20
Chapter 21
Chapter 22
Chapter 23
Chapter 24

Preface
A multi-agent system (MAS) is a system composed of multiple interacting intelligent
agents. Multi-agent systems can be used to solve problems which are diﬃcult or im-
possible for an individual agent or monolithic system to solve. Agent systems are open
and extensible systems that allow for the deployment of autonomous and proactive
software components. Multi-agent systems have been brought up and used in several
application domains. This book is a collection 24 excellent works on multi-agent sys-
tems divided into four sections: Multi-Agent Systems Modeling; Control, Negotiation,
Reasoning, Tracking and Networking on Agents Environments; Multi-Agent Systems
Programming and Multi-Agent Systems Simulation and Applications.
Faisal Alkhateeb, Eslam Al Maghayreh and Iyad Abu Doush,
Yarmouk University,
Jordan

Part 1
Multi-Agent Systems Modeling

1
Requirements Modeling for
Multi-Agent Systems
Lorena Rodriguez1, Emilio Insfran1 and Luca Cernuzzi2
1ISSI Research Group, Department of Information Systems and Computation,
Universidad Politécnica de Valencia, Camino de Vera s/n 46022, Valencia,
2DEI, Universidad Católica “Nuestra Señora de la Asunción”, Campus Universitario,
C.C. 1683, Asunción
1Spain
2Paraguay
1. Introduction
The inadequate management of system requirements is a major cause of problems in
software development (Anton, 2006). Requirements Engineering is a branch of Software
Engineering and includes a set of activities concerning the identification, specification,
validation, and management of system requirements. However, a traditional approach to
requirements engineering may not be fully effective for certain complex systems that require
high levels or specific kinds of abstractions, and the need to define more specific
requirements engineering processes for these types of systems thus arises.
A Multi-Agent System (MAS) is a specific type of system that is composed of multiple
intelligent agents that interact with each other to achieve certain objectives. These systems
can be used to solve problems that it is difficult or impossible for a monolithic or a single
agent system to resolve. In recent years, various methodologies have been proposed to
guide the development of multi-agent systems, such as Tropos (Giorgini et al., 2005),
Ingenias (Gómez-Sanz & Pavón, 2003), Gaia (Zambonelli et al., 2003), etc. However, despite
the importance of the requirements phase in the development of software systems, many of
the proposed methodologies for the development of MAS do not adequately cover the
requirements engineering phase (Cernuzzi et al., 2005), focusing mainly on the design and
implementation phases. Moreover, a recent study on the application of requirements
engineering techniques in the development of a multi-agent system (Blanes et al. a, 2009)
found that 79% of the current methodologies for MAS development use requirements
engineering techniques which have been adapted from other paradigms (object orientation,
knowledge engineering, etc.) (Anton, 2006). However, these techniques and notations may
not be sufficient to cover the nature of MAS, since these systems, along with their
organizational, structural, or functional properties, characteristics that are not normally
necessary in conventional software systems such as pro-activity, adaptability, collaboration,
truth, or disposition (Blanes et al. a, 2009). These characteristics are denominated as social
behavior (Hector & Lakshmi, 2005). Therefore, there is a need for new methods and
techniques that enable the appropriate acquisition and treatment of MAS requirements.

Multi-Agent Systems - Modeling, Control, Programming, Simulations and Applications
4
(Blanes et al. b, 2009) and (Rodriguez et al., 2009) present two proposals for the acquisition
and modeling of requirements for the Gaia (Zambonelli et al., 2003) methodology which
covers the analysis and design phase of MAS. Based on the experience using these
approaches, this chapter presents an evolution of these earlier proposals to support the
acquisition and modeling of requirements regardless of the analysis and design
methodology used, and covers four essential perspectives of a MAS: organizational,
structural, functional, and social behavior.
It is also worth mentioning that agent technology is useful in many complex domains: e-
commerce, health, stock market, manufacturing, games, etc. In particular, we are interested
in the game development domain since it comprises a set of characteristics such as
collaboration, negotiation, trust, reputation, etc., which specially can be dealed with a MAS.
According to Google Trends and the ESA annual report (ESA, 2010), games development is
one of the business markets that has undergone most growth in the last few years. In
addition, the agent-oriented paradigm is one of the most promising for modeling such
business market due to the social behavior characteristics (negotiation, cooperation, etc.) of
the agents and the complexity that MASs can support. For this reason, in the next chapter,
we illustrate the feasibility of our approach by applying the requirements modeling process
to the development of the strategic board Diplomacy Game (Fabregues et al., 2010).
The structure of this chapter is as follows. Section 2, discusses the related works. Section 3,
describes the organizational, structural, functional and social behavior perspectives that
were considered when modeling MAS. Section 4, presents the requirements modeling
proposal. Section 5, focuses on the case study of the Diplomacy Game. Finally, section 6,
concludes and introduces future research work.
2. Related work
The importance of the requirements phase in software development is widely known.
However, capturing and modeling the requirements of a system is not a trivial task. In
particular, MAS require abstractions, techniques, and notations which have been specifically
tailored to this domain. We propose four basic perspectives for the modeling of MAS
requirements: organizational, structural, functional, and social behavior. This section, presents
some proposals for the acquisition and modeling of requirements that cover these four
perspectives of a MAS.
The organizational perspective is supported in proposals such as GBRAM (Anton, 2006).
GBRAM is a relevant traditional goal-oriented requirements engineering proposal. It
provides a procedural guide for the identification and development of goals and introduces
techniques that assist in their methodical and systematic analysis. GBRAM has a great
deficiency in terms of formality. This includes the lack of models, formal notations and tools
that support the modeling that the method uses. Nevertheless, the guidelines and the level
of clarity it offers are very good. Moreover, GBRAM also emphasize the verification of the
requirements through its refinement stage which specifies certain guidelines to follow, thus
making this process more reliable. Therefore it is possible to track the requirements
captured, and this is reflected in the traceability offered by the method.
Another proposal for requirements modeling that supports the organizational perspective is
the i * framework (Yu, 1997). This framework has been established as the basis for the
Tropos methodology (Giorgini et al., 2005). Tropos has been appropriately adapted to the
acquisition and modeling of the actors in the system and its environment, i.e., the actors,

goals, tasks, interactions, dependencies, resources needed, etc. However, it does not permit
a full representation of constraints nor does it propose a modeling environment. Since we
consider goal orientation to be of particular interest in the capturing of requirements for
MAS, we believe that it is necessary to analyze other methods which are complementary to
this approach.
The structural perspective is supported by proposals such as AUML (Odell et al., 2000).
AUML tends to be asserted as a notational standard in various methodologies; one of the
most common proposals for the requirements phase is the adoption of Use Case diagrams.
This formalism has shown good results for the representation of functional requirements
and is also a good tool for communication with stakeholders. Nevertheless, Use Cases have
limitations in capturing qualitative aspects of the environment and interactions with it. In
addition, a interesting contribution of AUML is the Agents Interaction Protocol (AIP), which
constitutes a central aspect for MAS, specified by means of protocol diagrams.
Another proposal that covers the structural perspective is KAOS (Van Lamsweerde et al.,
1998), a proposal for modeling requirements through goals. KAOS consists of a specification
language, a method of elaboration, and the meta-level knowledge which is used as a guide.
A KAOS model contains goals, information system requirements, expectations about the
system environment, conflicts between goals, obstacles, entities, agents, etc. One of the
strengths of the proposal is that of its use of formality to achieve correction. Moreover, the
idea of constraint is useful in identifying some of the external problems of integrity, and this
contributes to the robustness of the system. However, the successful implementation of the
method depends heavily on the developer’s experience in the domain and how well defined
the problem to be solved is (Huzam & Maibaum, 2006).
Other proposals do not support the organizational and structural perspective. This is the
case of CREWS (Maiden, 1998), which focuses on the perspectives of functional and social
behavior. CREWS is based on system object models that are abstractions of the key features
of the different qualities of the problem domain. CREWS uses these models to generate
normal course scenarios, and it then uses the theoretical and empirical research into
cognitive science, human-computer interaction, collaboration systems and software
engineering as a basis to generate alternative courses for these scenarios. A potential
weakness of the CREWS approach is that the generation of scenarios is domain-oriented, in
contrast with the goal-oriented scenario analysis and the task-oriented Use Case modeling.
If the scenarios are intended to validate the requirements, these requirements should be
oriented towards the generation of scenarios.
In summary, the organizational perspective is covered by proposals such as GBRAM and i *,
and the structural perspective is covered in proposals such as KAOS and AUML. Most of
the proposals presented in some way cover, either totally or partially, the functional and
social behavior perspective, as in the case of CREWS. However, to the best of our knowledge
no methods that completely cover all four perspectives needed for the development of a
MAS exist.
3. Different perspectives for multi-agent systems
This work aims to provide a solution to the lack of RE modeling approaches that
appropriately cover the four perspectives of MASs: organizational, structural, functional, and
social behavior. In order to contextualize these perspectives, an overview of them is presented

6
which emphasizes both social behavior and organizational aspects, since these are key
aspects for the development of MASs.
3.1 Organizational perspective
In the organizational perspective, the organization is represented as a system that has
certain goals. The organization attains these goals through consistent actions, which use
system resources and alter the desired system state (Falkenberg, 1998). Some authors such as
(Zambonelli et al., 2003) consider that the human organizational metaphor is very adequate
for systems which are situated in open and changing environments. They define a MAS as a
software system that is conceived as the computational instantiation of a group of
interacting and autonomous individuals (agents). Each agent can be seen as playing one or
more specific roles: it has a set of responsibilities or goals in the context of the overall system
and is responsible for pursuing these autonomously. Furthermore, interactions are clearly
identified and localized in the definition of the role itself, and they help to characterize the
overall structure of the organization and the agent’s position in it. The evolution of the
activities in the organization, which is derived from the agents’ autonomous execution and
from their interactions, determines the achievement of the application goal.
3.2 Structural perspective
The structural perspective shows the system architecture in terms of entities and the static
relationship between them. The modeling of these entities and relationships provides an
abstract structural perspective of the system. We believe that this perspective is necessary to
identify the entities that will be needed to build the future MAS. If the static and structural
relationships are to be captured accurately, the development method must include
formalisms and techniques to specify relationships of hierarchy (inheritance), semantic
dependency (association) and part-of relations (aggregation).
3.3 Functional perspective
The functional perspective shows the semantics associated with the organizational roles’
services that are motivated by the occurrence of events. In this context, we understand an
organizational role to be the representation of an abstract entity that provides (multiple)
system methods or services. An event is something that occurs in the environment and to
which the organizational role reacts by running a method or service. This perspective
focuses to model the functional requirements to be met by the roles in the future MAS.
3.4 Social behavior perspective
The social behavior perspective shows the possible sequences of events or services to which
an agent can respond or that occur in its lifetime, along with interaction aspects such as
communication between agents, and this is often represented as state or activity diagrams.
As is discussed above, in addition to organizational, structural, and functional properties, a
MAS also requires characteristics that are not normally required in conventional software
systems, such as pro-activity, adaptability, collaboration, truth, or disposition. These
characteristics are denominated as social behavior. We therefore believe that covering this
perspective in a proposal for modeling requirements for MAS is an important contribution
towards the development of such systems, since the essence of these systems is the
performance of complex tasks that other types of systems are not capable of solving.

3.4.1 Classification
In order to properly structure and organize the features of social behavior requirements, we
briefly present the classification scheme of agent characteristics defined in (Hector &
Lakshmi, 2005). According to the authors, three main attributes of an agent are defined: (a)
autonomy, which refers to the fact that an agent should run independently, with little or no
human intervention, (b) temporal continuity, which signifies that an agent should run
continuously rather than simply perform a task and finish, and (c) social skills, which
signifies that an agent should possess some form of social skills, since the agent’s
advantages lie in its interactive communication with other agents. In addition to these core
attributes, an agent can also be classified according to the following social behavior
characteristics:
a. Pro-activeness: this refers to how the agent reacts to -and reasons about - its
environment, and how it pursues its goals. The agent can directly react to stimuli in its
environment by mapping an input from its sensors directly to an action, or it can take a
purely planning, or goal-oriented, approach to achieve its goals. This last approach
relies upon utilizing planning techniques.
b. Adaptability: this describes an agent's ability to modify its behavior over time. In fact, the
term “agent” is often taken to implicitly mean “intelligent agents”, which combine
traditional artificial intelligence techniques to assist in the process of autonomously
performing tasks. This feature includes other sub-features such as learning and sub-
submission.
c. Mobility: this refers to the agents’ capability of transporting their execution between
machines on a network. This form of moving can be physical, where the agent travels
between machines on a network, or logical, where an agent which is running on a single
machine is remotely accessed from other locations on the Internet.
d. Collaboration: collaboration among agents underpins the success of an operation or
action in a timely manner. This can be achieved by being able to coordinate with other
agents by sending and receiving messages using some form of agent communication
language, and permits a high degree of collaboration, thus making social activities such
as distributed problem solving and negotiation possible. Moreover, it is possible for
agents to collaborate without actual communication taking place. The interaction of
agents with resources and their environment may lead to the emergence of
collaborative or competitive behavior.
e. Veracity: this refers to the agent’s ability to deceive other agents via their messages or
behavior. An agent can thus be truthful in failing to intentionally deceive other players.
Moreover, an agent that is untruthful may try to deceive other agents, either by
providing false information or by acting in a misleading way.
f. Disposition: this refers to the agent’s “attitude” towards other agents, and its willingness
to cooperate with them. An agent may always attempt to perform a task when asked to
do so (benevolent), or may act in its own interests to collaborate with other agents only
when it is convenient to do (self-interested), or it might try to harm other agents or
destroy them in some way (malevolent).
The above characteristics in the classification represent to some extent abstraction of human
social behavior, and are those that differentiate agent paradigms from traditional software
development. In this work, we use this classification to study the characteristics of social
behavior and to propose mechanisms for the definition and specification of requirements of

8
these types. In particular, and as a starting point, in this work we will focus on the following
characteristics: proactiveness, collaboration, veracity, and disposition. Other characteristics
such as adaptability or mobility will be considered in future work.
Social behavior is a skill that must have an agent in a MAS. Moreover, if we consider the
organizational metaphor, an agent can, at different times in its life-cycle, play one or more
specific roles, which in turn have a set of responsibilities and goals. We therefore propose to
identify these features of social behavior in the requirements modeling process at role level,
through an analysis of the goals that need to be attained. Therefore, in the later phases of
the software development, when an agent has to be defined, the corresponding roles of
which a given agent will be composed will determine the agent’s complete social behavior.
4. Modeling requirements for multi-agent systems
To support the organizational, structural, functional and social behavior perspectives, we
propose a requirements modeling process which is decomposed into two main activities:
Requirements Definition and Requirements Specification. The user’s specific needs are
identified in the Requirements Definition activity. In particular it is identified: the
organizational structure of the system; the roles that are required in each sub-organization;
the roles goals; the social behavior needed for the roles to carry out their goals; and relevant
entities of the environment. The detailed requirements for developers are specified in the
Requirements Specification activity. The specifications extracted from the Requirements
Definition activity are refined, and the level of detail increased, in order to identify artifacts
which are closer to the analysis and development of the system: activities and interactions,
resources of the system, the permissions that roles have in those resources and
organizational rules.
Moreover, the process is based on the definition of models needed to describe the problem
in more concrete aspects that form the different perspectives of the system. In particular, in
the Requirements Definition activity it is possible to identify: (a) a Refinement Tree, which
identify and represent the goals of the system and their hierarchy, the roles that will carry
out these goals in an organizational context, and the organizational structure of the system,
and (b) a Domain Model with which to represent the entities that could be used as the
organization’s resources. In turn, the Refinement Tree, as is specified by the above
description, represents: (i) Mission Statement, which is the main objective that the system
under development provides the environment with in order to identify the overall goal
within the organization as a whole; (ii) Organizational Model, to represent the sub-
organizations of which the global organization is composed; (iii) Role Model, to represent the
roles involved in each sub-organization, the inheritance relationships between them, and
the social behavior needed between roles to accomplish their goals; and (iv) Goal Model, to
represent the goals associated with each role.
Moreover, in the Requirements Specification activity it is possible to identify: (c) a Behavior
Model, to represent the decomposition of goals into tasks and protocols in order to
understand the internal flow of a role to determine its responsibilities, (d) an Environment
Model, to represent the permissions of the roles identified in the Role Model with regard to
the resources of the Domain Model; and (e) an Organizational Rules Model, to represent the
constraints of the organization’s behavior.

Fig. 1. Models of the proposal and its relationship
In order to obtain a clear view of the models used, each of them is presented as follows. The
Mission Statement is defined in natural language, with a recommended extension of one or
two paragraphs. Since the Mission Statement identifies the overall goal within the
organization as a whole, it provides us with information about the organizational and
functional perspectives. The Mission Statement is the root of the Refinement Tree. It is
successively refined to identify the goals of the system to be represented as leaf nodes in the
tree. It is possible to distinguish three general levels in this process: (i) we first define the
decomposition of the system in a hierarchy of sub-organizations, thus representing the
Organizational Model. A sub-organization is a part of the system that aims to achieve a goal
in the system and weakly interacts with other parts of the system (low coupling); (ii) we
then decompose the sub-organizations into roles that partially represent the Role Model. A
role is the representation of an abstract entity that has (multiple) system goals; (iii) and
finally, we identify the goals of the system and a hierarchy of them, thus representing the
Goal Model. The goals are tasks which are carried out by a role in the sub-organization. The
structure of the Refinement Tree allows us to identify elements of the organizational
perspective through the decomposition of the system into sub-organizations; elements of the
structural perspective by identifying the roles that make up the sub-organizations and
finally aspects of the functional perspective by identifying the goals that each role has to
perform. As was previously mentioned, the Role Model describes the roles that belong to the
sub-organizations of the Refinement Tree. The purpose of this model is to represent the
different roles found in each sub-organization and to reason about their special
relationships. The special relationships between roles can serve to identify the common
properties between the roles in order to create a hierarchy of roles using inheritance
relationships and the identification of the social behavior relationships between roles in
different sub-organizations. The resulting Role Model comprises the information represented
in the Refinement Tree: one diagram for the inheritance relations between roles and one or
more diagrams as needed for each sub-organization for the social behavior relations

10
between roles. The UML Use Case Diagram is used to represent this information and
complement the Refinement Tree representation of roles. The roles are represented as actors
which are labeled with the stereotype <<role>>.In addition, the inheritance relations are
represented with the corresponding diagram relation, and the social behavior relations are
represented as relations labeled with the stereotypes <<collaboration>>, <<disposition>>
and <<veracity>>. We propose naming the relations with the corresponding property (i.e.
for the social behavior relation collaboration the relation is named as “communicative”, “non-
communicative” or both, for the social behavior relation disposition the relation is named as
“benevolent”, “self-interested”, “malevolent” or the combinations, and finally for the social
behavior relation veracity the relation is named as “truthful”, “untruthful” or both). A social
behavior relation between two roles could be of one or more property, since the relation is
dynamic, i.e. it may alter depending on the agent that will eventually play the role. This
information allows us to express elements of the structural, organizational and social
behavior perspectives.
The Domain Model represents the entities identified in the problem domain. The purpose of
this is to identify key concepts and relationships, thus representing a first structural view.
These entities are seen from the point of view of the application domain, and
implementation details are therefore avoided at this level. Associations and inheritance
relationships between domain entities are also represented. The identification of these
domain entities and their relationships allows us to extract information for the structural
perspective and to partially extract information for the organizational perspective. The UML
Class Diagram will be used to represent this information.
The Behavior Model shows a sequence of steps that represent the flow of activities needed to
achieve the goals identified in the system. A representation of the flow of tasks could be
useful: to understand the logical flow of a role; to complement the information regarding
social behavior identified in the Role Model; and to help to identify new information when
one role needs to work with others in order to accomplish a task. The identification of the
flow of activities allows us to extract information for the functional perspective.
Furthermore, the identification of interactions between different roles allows us to identify
information for the social behavior perspective. The UML Activity Diagram will be used to
represent this information.
The Environment Model represents the permissions of the roles with regard to the entities
identified in the Domain Model. For each role identified in the Role Model, resources are
established for those who can legitimately access them. Finally the permissions (perceive or
modify) are established. The identification of these permissions offers information of the
structural and functional perspectives of the system. The UML Use Case Diagram is used to
represent this information, and the roles are represented as actors which are labeled with the
stereotype <<role>>, the resources are represented as classes and the permissions are
represented as relations between the role and the entity, which are labeled with the
stereotypes <<perceive>>, and <<modify>.
The Organizational Rules Model identifies and represents the general rules concerning the
organization’s behavior. These rules can be viewed as general rules, responsibilities,
restrictions, the desired behavior, and the sequence or order in such conduct. These rules
will be represented by building on GBRAM, in which two types of dependency
relationships between goals are distinguished: precedence and restriction, which are
represented by the symbols < and Æ respectively, and by adding a relationship to the

proposal to represent general rules of the system, which is represented with only natural
language. This information contributes to extract information for organizational, structural
and functional perspectives of the system. We suggest that the set of rules should be
represented with a table schema in which each rule is defined by a natural language
description of the relationship, the type and the corresponding formula if necessary.
Each of these models provides the information which is necessary to cover the different
perspectives of a MAS: (i) structural (Domain Model, Role Model, and Environment Model); (ii)
organizational (Mission Statement, Organizational Model, Roles Model, Domain Model, and
Organizational Rules Model); (iii) functional (Mission Statement, Goal Model, Behavior Model,
Environment Model and organizational Rules Model); and (iv) social behavior (Role Model and
Behavior Model). Figure 1 shows an overview of these models and their respective relations.
The process for defining and specifying the requirements is described in the following
subsection.
4.1 Requirements modeling process
As was mentioned earlier, the requirements modeling process proposed involves two
phases: Requirements Definition and Requirements Specification. Figure 2 shows an overview of
this process, using the SPEM graphical notation (OMG, 2010). Each activity of the process
produces a document that is composed of the sum of all the models and documents of the
working definition that is included in each activity. The Requirements Definition activity tasks
are performed first, thus producing the requirements specification. The Requirements
Specification activity tasks are then performed, using the requirements specification
produced in the previous activity as input and resulting in the production of the refined
requirements specification. At this point the Requirements Definition activity can again be
performed in case some kind of inconsistency or incompleteness is encountered in the
specification, or the process may end.
Requirements
Specification
Refined
Requirements
Specification
Requirements
Definition
Requirements
Specification
[valid]
[not valid]
Fig. 2. Requirements modeling process overview

12
4.1.1 Requirements definition
The Requirements Definition activity consists of three tasks whose aim is to identify the
models of the phase, as is shown in Figure 3. The first task is to Create Refinement Tree,
beginning with the definition of the Mission Statement which is then broken into sub-
organizations, roles and goals. This information is part of the Mission Statement,
Organizational Model, Role Model and Goal Model. The list of roles identified in the previous
task will be used as input for the next task: Refine Roles. Here we discuss possible structural
similarities in order to identify inheritance relationships, and we analyze the goals to be
attained by each role in each sub-organization in order to identify the social behavior
relationships between them. If deemed appropriate, it is possible to return to the previous
task in order to update the Refinement Tree, or the next task can be performed. In the last
task, Identified Entities, the Domain Model is constructed from the identified entities, and
association and inheritance relationships among them are defined.
Refinement Tree
Create
Refinement
Tree
Refine Roles
Identified
Entities
Organizational
Model
Role Model Domain Model
Role Model
Goal Model
Mission
Statement
Fig. 3. Requirements Definition activity decomposed into tasks and artifacts
4.1.2 Requirements specification
The Requirements Specification activity involves the creation of three models: Behavior Model,
Environment Model and Organizational Rules Model, and therefore consists of three tasks for
the creation of the models, as is shown in Figure 4. The first task in this activity is Create
Activity Diagrams. The Organizational Model, Role Model, Goal Model of the Requirements
Definition activity are used as input. The necessary Activity diagrams are created as a result
of this. When this has been completed, the next task is performed: Develop Environment
Model. The Role Model and the Domain Model of the Requirements Definition phase are taken
as input. Then, the Define Organizational Rules task is performed, taking as input the Role
Model of the Requirements Definition activity and the Environment Model of the current
activity. The Organizational Rules Model is produced as a result of this.

Create Activity
Diagrams
Behavior Model
Organizational
Model
Role Model
Goal Model
Develop
Environment Model
Define Organizational
Rules
Domain Model
Environment Model Organizational Rules Model
Fig. 4. Requirements Specification activity decomposed into tasks and artifacts
Finally, the artifacts generated during the process can relate to analysis and design artifacts
from other methodologies by establishing a traceability framework. This will increase the
overall quality of the system to be.
5. Case study: diplomacy game with agents
We have used the Diplomacy Game to verify the feasibility of our approach in areas such as
negotiation, argumentation, trust and reputation (Fabregues et al., 2010) in the game
development domain. Many interesting features make the Diplomacy Game compelling for
the applying the agent technology: the absence of random movements, all players move
their units simultaneously, all units are equally strong so when one attacks another the
winner of the battle is decided by considering solely the number of units helping one
another, etc. Accordingly, from a player’s point of view, the most important feature of the
game is the negotiation process: deciding allies, selecting who to ask for help, arguing with
other players to obtain information about their objectives or to discover what they know,
and so on. We have used the rulebook of the Diplomacy Game (Wizards, 2010) as a
description of the system to be modeled with the process proposed in this work. The most
relevant aspects of the game are provided as follows.
The Diplomacy Game is played by seven players and a Game Master. Each player represents
one of the seven “Great Powers of Europe” in the years prior to World War I. These Great
Powers consist of England, Germany, Russia, Turkey, Italy, France, and Austria. At the start
of the game, the players randomly decide which Great Power each will represent. This is the
only element of chance in the game. As soon as one Great Power controls 18 supply centers,
it is considered to have gained control of Europe. The player representing that Great Power
is the winner.
Diplomacy is a game of negotiations, alliances, promises kept, and promises broken. In order
to survive, a player needs help from others. In order to win the game, a player must
eventually stand alone. Knowing who to trust, when to trust them, what to promise, and
when to promise it is the heart of the game.
At the beginning of each turn, the players meet together in small groups to discuss their plans
and suggest strategies. Alliances between players are made openly or secretly, and orders are

14
coordinated. Immediately following this period of “diplomacy,” each player secretly writes an
order for each of his or her units on a slip of paper. When all the players have written their
orders, the orders are simultaneously revealed, and are then all resolved. Some units are
moved, some have to retreat, and some are removed. Resolving orders is the most challenging
part of the rules and requires complete knowledge of the rules. Each turn represents six
months of time. The first turn is called a Spring turn and the next a Fall turn. After each Fall
turn, each Great Power must reconcile the number of units it controls with the number of
supply centers it controls. At this time some units are removed and new ones are built. The
purpose of the Game Master is to keep time for the negotiation sessions, collect and read
orders, resolve issues, and make rulings when necessary. This role should be strictly neutral.
Each turn has a series of phases: (a) Spring four-phase turn: Diplomatic phase, Order
Writing phase, Order Resolution phase, Retreat and Disbanding phase; (b) Fall five-phase
turn: Diplomatic phase, Order Writing phase, Order Resolution phase, Retreat and
Disbanding phase, Gaining and Losing Units phase. After a Fall turn, if one Great Power
controls 18 or more supply centers, the game ends and that player is declared the winner.
Based on the tasks of the Requirements Definition and Requirements Specification activities
proposed, and which were presented in the previous section, the development of the case
study is presented below.
5.1 Requirements definition
The requirements modeling process starts with the Requirements Definition activity. This
activity starts with the first task: Create Refinement Tree. First the Mission Statement of the
system must be defined, which in this case is simple and is the Management of the Diplomacy
Game. For the definition of the sub-organizations of the system we decided that the problem
naturally leads to a conception of the whole system as a number of different MAS sub-
organizations, one for each phase of the game, and one extra sub-organization representing
the start of the game. The resulting sub-organizations are: Initial phase, Diplomatic phase,
Writing Order Phase, Order Resolution phase, Retreat and Disband phase and Gaining and Losing
Units phase. This concept of representing the sub-organizations of the system as phases was
also used in (Zambonelli et al., 2003). The roles that are part of each sub-organization are
then defined, resulting in three roles: Great Power, Game Master and Unit which, depending
on which sub-organization they are, have different goals. Finally the roles are refined with
the goals they need to attain in order to fulfill each sub-organization’s objective. For example
in the Order Resolution Phase sub-organization, the Game Master role has the goal of Resolve
Order Conflicts and the Unit role has the goal of Follow Orders. Figure 5 shows the complete
resulting Refinement Tree.
The second task, Refine Role Model, is performed to complete the Role Model based on the
information defined in the Refinement Tree. Possible inheritance relationships between roles
can be specified in this task. The goals of each role in each sub-organization are also
reviewed in order to identify whether the role needs social behavior relationships in any
sub-organization. Owing to space limitations we shall only illustrate the Role Model showing
one of the most significant diagrams (see Figure 6). However, the same analysis should be
performed for all of the sub-organizations, thus resulting in one or more Social behavior
diagrams for each sub-organization. Upon analyzing the goals of the roles of the Diplomatic
Phase sub-organization, we identified that the Great Power role needs to have the
collaborative relation to attain all of its goals in the sub-organization analyzed, and more
specifically, the role needs to be communicative with other instances of the Great Power role

and with the Game Master role. The same applies in the case of the Game Master role fulfilling
its Control Negotiation Session goal: the collaborative relationship will be with the Great Power
role. The collaborative relationship between Great Power and Game Master will therefore be
on both sides, represented with a non-directional arrow. Moreover, if the Great Power role is
to fulfill all of its goals in the sub-organization analyzed, it needs to be benevolent, self-
interested or malevolent with regard to another instance of the Great Power role, depending on
the agent’s intentions. In this sub-organization, negotiation, persuasion and trust are keys to
the Great Power role. On the other hand, the Great Power role in the sub-organization analyzed
is in all cases benevolent with regard to the Game Master role, and vice versa. Finally, we
believe that it is necessary for the veracity relation between the Great Power role and other
instance of the same role to be truthful or untruthful, again depending on the intentions of the
agent playing the role. We also believe that it is necessary for the veracity relation between the
Great Power role and the Game Master role to be truthful in both directions.
Fig. 5. Diplomacy game Refinement Tree
Fig. 6. Social behavior diagram showing relations between roles in the Diplomatic phase sub-
organization (collaboration, veracity, and disposition)

16
The third task, Identify entities, is performed to define the Domain Model. Figure 7 shows the
Domain Model generated. Briefly, the domain consists of a Map that is composed of many
Countries which in turn have Boundaries and Provinces. A Province can be an Inland, Coastal or
Water province. A Supply Center is in a Province, but a Province may or may not have a Supply
Center. Furthermore, a Unit is in a Province, but a Province may or may not have a Unit. A
Unit can be an Army or a Fleet. Both a Province and a Unit belong to a Great Power which in
turn is a Country, but not all Countries are Great Powers. A Great Power has many Documents,
Orders, Retreats and Adjustments, and they all belong to only one Great Power. Orders, Retreats
and Adjustments are all for one Unit and a Unit follows many Orders, Retreats and
Adjustments.
Fig. 7. Diplomacy game Domain Model
As a result of performing the Requirements Definition activity we obtain the Refinements Tree
shown in Figure 5, which represents the Mission Statement, Organizational Model, partially the
Role Model and Goal Model. One or more Social behavior diagrams is needed for each sub-
organization, thus complementing the information of the roles in the Refinement Tree to
complete the Role Model. An example of this is shown in Figure 6. Finally, the UML Class
Diagram which relates the entities identified in the domain to represent the Domain Model
are shown in Figure 7.
5.2 Requirements specification
The second activity is to perform the Requirements Specification, which starts with the first
task, Create Activity Diagrams, in order to specify the Behavior Model using the information
from the Organizational Model, Role Model, and Goal Model generated in the Requirements
Definition activity as input. Once again, owing to space limitations we shall only illustrate

one Activity diagram from the Behavior Model (see Figure 8). However, the same analysis
must be carried out for each goal identified in the Goal Model, resulting in one or more
Activity diagrams for each goal. The presented activity diagram specifies the activities and
protocols performed by the Great Power role to attain the Make Alliance goal and the activities
and protocols performed by the Game Master role to attain the Control Negotiation Sessions
goal, both of which are roles of the Diplomatic phase sub-organization. As the goals of these
two roles are related, we decide to specify their activity diagrams in just one diagram with
tree swim lines, two for the interaction between the two instances of the Great Power role
(active and passive) to attain the Make Alliance goal, and the third for the interaction between
the Game Master role and the instances of the Great Power role to attain the Control Negotiation
Sessions goal.
As is shown in Figure 8, the flow of actions performed by the Great Power active role to
attain the Make Alliance goal begins with a fork that gives the control to one initiator
protocol: Meet in private groups, and to one reactive protocol: Interrupt negotiation session
(Game Master). The first protocol is initialized by the Great Power active role and result in the
reactive protocol Meet in private groups (Active:Great Power) of the Great Power passive role,
while the other is a reaction of the Great Power role to the Interrupt negotiation session protocol
initialized by the Game Master role if the negotiation time has ended. If this protocol is
performed, the Great Power active role must terminate the flow of action.
After the Meet in private groups protocol has been performed, the Great Power active role
must perform the Decide who to trust activity in order to attain the Make Alliance goal. The
Great Power passive role has the same flow of actions as the Great Power active role, with the
difference that its Meet in private groups (Active:Great Power) protocol is a reaction to the Meet
in private groups protocol initialized by the Great Power active role, and since this is a passive
instance of the Great Power role, it does not end the flow of actions.
Active:Great Power :Game Master
Meet in private
groups
Decide who to trust
Is Time
to
finish?
No
Si
Interrupt negotiation
session
session
(Game Master
)
Passive:Great Power
Decide who to trust
session
(Game Master
)
Meet in private
groups
(Active :Great Power)
Fig. 8. Activity Diagram for the goals Make Alliance and Control Negotiation Session

18
The second task that must be performed in the Requirements Specification activity is Develop
Environment Model using the information from the Role Model and Domain Model generated
in the Requirements Definition activity as input. Figure 9 shows the permissions of the Great
Power, Game Master and Unit roles with regard to the Domain Model resources that each role
needs to perceive or modify in order to attain its goals. The Great Power role perceives the
following entities in the system: other instances of Great Power, Units, Map, Provinces,
Boundary and Country; and can modify: Supply Center, Document, Order, Retreat and
Adjustment. The Game Master role perceives the following entities in the system: Great Power,
Units, Map, Provinces, Supply Center, Boundary and Country; and can modify: Order, Retreat
and Adjustment; but cannot perceive or modify the Document entity. Finally the Unit role
perceives the following entities in the system: Great Power, Map, Provinces, Boundary,
Country, Document, Order, Retreat and Adjustment; but cannot perceive or modify the
following entities: other instances of Unit and Supply Center.
The third task that must be performed in the Requirements Specification activity is to Define
Organizational Rules, using the information from the Domain Model generated in the
Requirements Definition activity and the Behavior Model of the current activity as input. In the
current domain, the important rules to identify are the general rules of the game, the
number of players, the rules concerning the movement of the units depending on the type of
unit and on the type of provinces the move take place in, etc. Table 1 shows an extract from
the Organizational Rules Model.
Fig. 9. Diplomacy game Environment Model
Finally, as a result of performing the Requirements Specification activity we obtain the Behavior
Model which is composed with all the Activity diagrams (see example in Figure 8). We also
obtain the Environment Model (see Figure 9). And finally, a table representing the
Organizational Rules Model is obtained (see Table 1).

Description
The game is divided into a two year tour: Spring four-phase turn and Fall five-phase turn
Spring four-phase turn has phases: Diplomatic, Order Writing, Order Resolution and
Retreat and Disbanding
Fall five-phase turn has phases: Diplomatic, Order Writing, Order Resolution and Retreat
and Disbanding, Gaining an Losing
Only seven players may perform the role of "Great Power"
When 18 supply centers belongs to a "Great Power" the game ends and the winner is that
"Great Power"
At the start of the game each “Great Power”, except Russia, controls 3 supply centers
At the start of the game, the “Great Power” Russia controls 4 supply centers
Maximum time in the first diplomatic phase is 30 minutes
Table 1. Extract of Organizational Rules Model
5.3 Discussion
With the definition of the Diplomacy Game Refinement Tree (see Figure 5), the requirements
engineer is able to identify the overall goal of the system, the decomposition of the system in
a hierarchy of sub-organizations, roles involved in each sub-organization, and the goals
which are carried out by each role in the corresponding sub-organization. The Diplomacy
Game Refinement Tree provides information for the organizational, functional, and structural
perspectives of the case study system. In addition, the social behavior needed for each role
to carry out their goals is specified by mean of one Social behavior diagram for each sub-
organization (see Figure 6). The case study presents a variety of social characteristics that
allow to fully evaluating the proposed Social behavior diagram. In particular, we identified
relationships of collaboration, disposition and veracity. The Social behavior diagrams
provide information for the social behavior perspective. Moreover, the relevant entities of the
environment of the game are identified in the Diplomacy Game Domain Model (see Figure 7),
providing information for the organizational and structural perspective.
With the construction of one Activity diagram for each goal, the requirements engineer is
able to refine each goal in activities and protocols, and also to refine the social behavior
identified in the previous activity. It is proper to mention that the collaboration relationships
identified in the Social behavior diagrams is refined in the Activity diagrams. As an
example, the initiator protocols and reactive protocols in Figure 8 show the specification of
the collaboration relation identified in the Social behavior diagram of Figure 6. The Activity
diagrams also provide information for the functional and social behavior perspectives.
Furthermore, the Diplomacy Game Environment Model (see Figure 9), identifies the resources
of the system, and defines the permissions that roles have in those resources, providing
information for the structural and functional perspectives. The organizational rules of the
game are specified (see Table 1), providing information for the organizational, structural and
functional perspectives.
Finally, due to its characteristics, the Diplomacy Game case study offers a good example to
validate the feasibility of our approach to model the requirements of a MAS covering its
organizational, structural, functional, and social behavior properties.

20
6. Conclusions and future work
In this work we proposed a requirements modeling process for MAS. The approach is
organized into two main activities: Requirements Definition and Requirements Specification. In
the Requirements Definition activity the following is modeled: (a) the organizational structure
and structural properties of the system; (b) the functional behavior of the system; and (c) the
domain entities and their relationships. In the Requirements Specification activity the
requirements specifications are refined, identifying: (a) the interactions on which the social
behavior of the system is based; (b) the mains activities which conform the functional
behavior of each role; (c) the permissions of the roles in the domain entities; and (d) the
structural and functional behavior. This process supports the four perspectives that
characterize a MAS: organizational, structural, functional and social behavior. We believe that
this proposal addresses the need for a requirements modeling process for MAS because it
incorporates specific abstractions needed to capture and specify these four perspectives. In
particular, the definition and specification of features of social behavior at the requirements
level will increase the quality of specifications, thus providing the expressiveness needed by
the MAS in an early stage of the software development process.
As a case study, we have presented the requirements modeling of the Diplomacy Game. The
game development domain, given its characteristics, particularly allows us to observe and
reason about different ways in which to identify, define, and specify requirements of social
behavior, in addition to the organizational (because of the various phases of which a game is
composed), the structural (owing to the different types of elements used), and the functional
(because of the different actions to be performed). Moreover, according to Google Trends
and the ESA annual report (ESA, 2010), game development is one of the business markets
that has undergone most growth in the last few years. The social behavior characteristics
(negotiation, cooperation, pro-activity, etc.) and complexity of games make them
appropriate subjects for resolution with the agent-oriented paradigm.
Currently, we are working on the definition and specification of other social behavior
characteristics, such as adaptability and mobility. In addition, plan to empirically validate
our approach through a series of experiments using game development experts as subjects.
We are also working to extend this agent proposal to a model-driven development approach
in the context of a project named Multi-modeling Approach for Quality-Aware Software
Product Lines (MULTIPLE). MULTIPLE focuses on the definition and implementation of a
technology framework for developing software product lines of high-quality software in the
context of model-driven development. This extension would facilitate the integration and
traceability among the artifacts generated during the requirements modeling process and
the analysis and design artifacts used in the MAS development. This will increase the
overall quality of the MAS to be developed. Finally, we plan to build a tool that will support
the overall process defined, using the Eclipse Development Environment (The Eclipse
Fundation, 2010).
7. Acknowledgments
This research is funded by the Ministry of Education and Science, under the National
Research Program, Development and Innovation, MULTIPLE project (TIN2009-13838).
Lorena Rodriguez has a scholarship under the College Scholarship Program and Support of
the Scientific and Technological Production, in the context of the Social Responsibility
Program of the Itaipu Binacional/Parque Tecnológico Itaipu-Py.

8. References
Anton, A. (1996). Goal-based requirements analysis. Proceedings of the 2nd International
Conference on Requirements Engineering (ICRE '96), pp.136–144, ISBN: 0-8186-7252-8,
Colorado Springs, April 1996, IEEE Computer Society, Colorado
Blanes, D.; Insfrán, E.; Abrahão, S. (2009) a. Requirements Engineering in the Development
of Multi-Agent Systems: A Systematic Review. Proceedings of the International
Conference on Intelligent Data Engineering and Automated Learning (IDEAL), pp. 510 –
517, ISBN: 0302-9743, Burgos, Spain, September 2009, Springer-Verlag, Berlin,
Heidelberg
Blanes, D.; Insfrán, E.; Abrahão, S. (2009) b. RE4Gaia: A Requirements Modeling Approach
for the Development of Multi-Agent Systems. International Conference on Advanced
Software Engineering and Its Applications (ASEA’09), pp. 245 – 252, ISBN: 978-3-642-
10618-7, Jeju Island, Korea, December 2009, Springer, Berlin
Cernuzzi, L.; Cossentino, M.; Zambonelli, F. (2005). Process models for agent-based
development. Engineering Applications of Artificial Intelligence, 18, 2, (March 2005)
page numbers (205 – 222), ISSN: 0952-1976
ESA (2010). Entertainment Software Association, Industry Facts. Last accessed on September
14, 2010, en http://www.theesa.com/facts/index.asp
Fabregues, A.; Navarro D.; Serrano A.; Sierra C. (2010). dipGame: a Testbed for Multiagent
Systems, Proceeding of the ninth International Conference of Autonomous Agents and
Multi-Agent Systems, Toronto, Canada, May 2010
Falkenberg, E.D.; Hesse, W.; Lindgreen, P.; Nilsson, B. E.; Oei, J.L.H.; Rolland, C.; Stamper,
R. K.; Van Assche, F.J.M.; Verrijn-Stuart, A. A.; Voss., K. (1998). FRISCO - A
framework of information system concepts — The FRISCO Report. Task Group FRISCO,
ISBN: 3-901882-01-4
Giorgini, P.; Kolp, M.; Mylopoulos, J.; Castro, J. (2005). Tropos: A Requirements-Driven
Methodology for Agent-Oriented Software. In: Agent-Oriented Methodologies, Brian
Henderson-Sellers; Paolo Giorgini, page numbers (20-45), Idea Group , ISBN:
1591405815, USA
Gómez-Sanz, J.; Pavón, J. (2003). Agent Oriented Software Engineering with INGENIAS,
Proceedings of the 3rd Central and Eastern Europe Conference on Multiagent Systems
(CEEMAS ‘03), pp. 394 – 403, ISBN: 3-540-40450-3, Prague, june 2003, Springer-
Verlag, Prague
Hector, A.; Lakshmi Narasimhan, V. (2005). A New Classification Scheme for Software
Agents. Proceedings of the Third International Conference on Information Technology and
Applications (ICITA’05), pp. 191 – 196, ISBN: 0-7695-2316-1, Sydney, Australia, July
2005, IEEE Computer Society, Washington, DC
Huzam S. F. Al-Subaie; Maibaum Tom S. E. (2006). Evaluating the Effectiveness of a Goal-
Oriented Requirements Engineering Method. Proceedings of the Fourth International
Workshop on Comparative Evaluation in Requirements Engineering, pp. 8 - 19, ISBN: 0-
7695-2712-4, Minneapolis/St. Paul, Minnesota, September 2006, IEEE Computer
Society Washington, DC
Maiden, N. (1998). CREWS-SAVRE: Scenarios for Acquiring and Validating Requirements.
Automated Software Engineering, 5, 4, (October 1998) page numbers (419 - 446), ISSN:
0928-8910

22
Odell, J.; Parunak, H. V. D.; Bauer, B. (2000). Extending UML for agents. Proceeding of the 2nd
Int. Workshop on Agent-Oriented Information Systems, pp. 3 – 17, Berlin, iCue
Publishing
OMG (Object Management Group). Software Process Engineering Meta-Model (SPEM),
version 1.1. Last accessed on March 11, 2010, en http://www.omg.org/cgi-
bin/doc?formal/05-01-06.pdf
Rodriguez L.; Hume, A.; Cernuzzi, L.; Insfrán, E. (2009). Improving the Quality of Agent-
Based Systems: Integration of Requirements Modeling into Gaia. Proceedings of the
Ninth International Conference on Quality Software (QSIC ‘09), pp. 278 – 283, ISBN:
978-0-7695-3828-0, Jeju, Korea, August 2009, IEEE Computer Society Washington,
DC
The Eclipse Foundation. Last accessed on September 2010, from http://www.eclipse.org
Van Lamsweerde, A.; Darimont, R.; Letier, E. (1998). Managing conflicts in goal-driven
requirements engineering. IEEE Transactions on Software Engineering, 24, 11,
(November 1998) page numbers (908 – 926), ISSN: 0098-5589
Wizards (2010). The rules of Diplomacy. The game of international intrigue. . Last accessed
on September 14, 2010 en
http://www.wizards.com/avalonhill/rules/diplomacy_rulebook.pdf
Yu, E. (1997). Towards Modelling and Reasoning Support for Early-Phase Requirements
Engineering. Proceedings of the 3rd IEEE Int. Symp. on Requirements Engineering (RE
‘97), pp. 226 – 235, ISBN: 0-8186-7740-6, Washington D.C., USA, January 1997
Zambonelli, F.; Jennings, N.; Wooldridge, M. (2003). Developing Multiagent Systems: The
Gaia Methodology. ACM Transactions on Software Engineering and Methodology
(TOSEM), 12, 3, (July 2003) page numbers (317 – 370), ISSN: 1049-331X

2
A Multi-Agent System Architecture for
Sensor Networks
María Guijarro, Rubén Fuentes-Fernández and Gonzalo Pajares
University Complutense Of Madrid, Madrid,
Spain
1. Introduction
Today it is increasingly important a good design architectures that support sensors. This
chapter shows how the design of the control systems for sensor networks presents
important challenges because of using sensor networks has design problems. Besides the
traditional aspects about how to process the data to get the target information, engineers
need to consider additional aspects such as the heterogeneity and high number of sensors,
and the flexibility of these networks regarding topologies and sensors in them.
The increasing availability of sensors plugable in networks at low costs is rapidly increasing
their use for different applications like smart spaces or surveillance systems (Tubaishat, M.
& Madria, S. 2003).These networks pose important challenges for engineers working in the
development of the related control systems. Some of the most relevant are:
• Potential high number of nodes. The current trend is to set up networks densely populated
with sensors and a minor number of controllers (Yick et al., 2008). These magnitudes
imply that engineers must consider issues such as the organization of the
communications and local pre-processing of data to save bandwidth and get suitable
response times.
• Sensor heterogeneity. These networks include a wide variety of types of devices (e.g.
cameras, motion sensors or microphones) whose management and usage differs (Hill et
al., 2000). These sensors are usually specialized in specific applications, so they do not
offer the same services. The combination of different types of sensors in a network and
the use of its data requires a high-level of modularity and adaptability in the
architecture.
• Changing network topology. Sensor networks are less stable than traditional computer
networks (Yick et al., 2008). Their sensors are more prone to fail than conventional
computational devices: they frequently operate unattended in environments that can
lead them to malfunction, and with very limited resources. A common way to
overcome sensor failure is redeploying new sensors, which further changes the network
topology. These changes make that the control of the network must deal with ad-hoc
topologies to attend the communications needs of a given moment with the available
resources.
• Several levels of data processing. Processing of data happens at both local and global levels
(Tubaishat, M. & Madria, S. 2003). Since sensors can be deployed over quite wide areas,
the management of data may need to be contextualized, for instance to determine what

24
signals are relevant in a situation. Nevertheless, centralized processing is also
necessary, mainly for the transformations and integration of data. Thus, the architecture
of the control must deal with groups at different levels that need to coordinate.
• Unreliable networks of reduced bandwidth. The network established in these cases is highly
unreliable when compared with wired networks (Yick et al., 2008). It is usually a
wireless network where the hostile environment produces intermittent connectivity
with a high variability in the conditions for communication. This issue requires
solutions similar to those of the changing topology.
These challenges have been addressed in several works, though usually focusing only on
the solutions for some specific issues. For instance, literature (Akyildiz et al., 2007; Baronti et
al., 2007; Tubaishat, M. & Madria, S. 2003; Yick et al., 2008) reports works on routing in ad-
hoc networks to minimize energy consumption, optimal data processing to reduce
computation time in sensors or data integration in specific domains. However, the
integration of the different solutions is not a trivial problem and research in architectures for
these networks pays attention to it.
The architectures proposed for these networks usually consider some basic infrastructure
and a component model. The infrastructure provides basic services for all the components,
and the components model specify the interfaces and behaviour that components must
provide to be integrated in the network. Examples of these works are the architectural
principles in (Estrin et al., 1999) and MADSN (Qi et al., 2001), TinyOS (Hill et al., 2000) and
Tenet (Gnawali et al., 2006). (Estrin et al., 1999) is probably one of the first works discussing
the specific problematic of sensor networks. It advocates for architectures where data
processing is performed as close as possible to the sources of those data, probably in the
sensors themselves. Sensors are also responsible of communication, sometimes supported
by communication specific devices. MADSN (Qi et al., 2001) proposes changing the
paradigm for data integration from one where all the data are transmitted to a central
processing node, to another in which mobile agents travel to the nodes that collect data and
make there the processing, propagating only ellaborated data. TinyOS (Hill et al., 2000) is
focused on infrastructure. It is an operating system based on micro-threading, events and a
simple component model. A component has tasks, commands and handlers that are
executed in the context of an encapsulated fixed-size frame, and they operate on the state of
the component. Tenet (Gnawali et al., 2006) is a model of components and its supporting
libraries built on top of TinyOS. It proposes a two-layered architecture with simple sensors
and masters. Sensors get data and only make basic signal processing. Masters perform the
integration of data using more powerful computational devices. These examples are also
illustrative of the main limitations of these architectures:
• Constraining architecture. Most of times, the architecture includes a restricted component
model. Systems need to adhere strictly to its principles, which imply developing
specific interfaces and conforming to certain rules of behaviour. This is the case of
TinyOS (Hill et al., 2000) and Tenet (Gnawali et al., 2006).
• Lack of a complete vertical solution. Although these architectures are conceived to integrate
the solutions of several aspects and to give complete models on how to build a sensor
network, they usually do not cover the whole design. For instance, most of the
proposed examples (Estrin et al., 1999; Gnawali et al., 2006; Hill et al., 2000) are mainly
related with communication and sensor management issues, but they do not say
anything about the design of the sensor controllers. Even if as proposed in (Estrin et al.,
1999) controllers are in sensors, the problematic of their design is focused more on

A Multi-Agent System Architecture for Sensor Networks 25
communications and data integration than on gathering data and the processing of the
raw signals.
• Lack of a supporting modelling language and development process. The proposed
architectures focus on design principles (Estrin et al., 1999; Qi et al., 2001) or
infrastructure (Gnawali et al., 2006; Hill et al., 2000). Nevertheless, this is not enough to
build a sensor network. Engineers need a development process that indicates them
what the relevant requirements to consider are, the design alternatives, and the steps to
follow in the development. The industrial use of such process demands customizable
modelling languages and automated support tools.
In order to address the previous limitations, some works have proposed multi-agent
systems (MAS) (Weiss, G., 2000) as the basis for the development of sensor networks. A
MAS is composed of a large number of agents and other computational artefacts. These
agents are social entities, which need to interact with other agents to achieve the satisfaction
of system goals. Agents are goal-oriented components, i.e. they rationally choose for
execution those actions that will potentially contribute to satisfy their objectives. These
choices depend on the information they have in their mental states about their environment,
past experiences and themselves. The works in this approach usually see sensors as devices
controlled by agents. This choice meets some of the aforementioned requirements of sensor
networks. Sensors are only responsible of data gathering and basic processing, while
computationally expensive processes are assigned to agents. This organization gives
freedom of choice to put the execution of data processing either mainly in the sensors or in
the controllers. Despite of this common feature, differences between approaches are
important. From the point of view of the goal of this work, they do not achieve a complete
architecture and process to design it either because they are too focused on some specific
issues (e.g. optimization of communications (Qi et al., 2001), only provide an architecture or
just a development process which is usually a general-purpose agent-oriented software
engineering (AOSE) methodology.
This work addresses these issues with a twofold solution: a standard architecture for sensor
networks able to deal with different design choices; a design language oriented to the kind
of abstractions appearing in it, and a development process for such systems. This chapter
focuses only on the first two elements, though it gives a brief introduction to the process. To
provide these elements, this work adopts as its basis a well-known general purpose AOSE
methodology, INGENIAS. INGENIAS (Pavón et al., 2005) covers the full-development cycle
from analysis to coding with a model-driven engineering (MDE) approach (Schmidt, D. C.
2006) supported by tools. The definition of its modelling language and tools is based on
metamodels. Metamodels are a common way of defining formally modelling languages in
MDE. The fact of having a formal definition of the language effectively constrains engineers
during design to build proper models, and it also allows automated processes for code
generation, both for tools and final systems. This allows its adaptation to new contexts by
means of extensions of its metamodel.
The architecture proposed in this work considers sensor networks composed by sensors and
controllers, therefore following common approaches with sensors and MAS (Pavón et al.,
2007). However, it extends both definitions in several ways. A sensor is defined as an
environment element with attached functioning parameters and an internal state, which can
be modified using its methods. The sensor is also able to perceive events coming from its
environment, and to raise events in order to notify changes in its state or that of its external
environment. The architecture considers sensor networks composed by devices (which

26
include sensors) and actors (i.e. agents). It extends common definitions for these concepts
(Pavón et al., 2007) in several ways.
A device is defined as an environment element with attached functioning parameters, an
internal state, and methods to work on that state. The device is also able to raise events in
order to notify changes in its state. A sensor is a device that perceives events coming from its
environment. Actors are similar to controllers in other approaches, but the architecture
introduces for them a neat separation of concerns with roles. A role is defined by its goals,
which are related with its responsibilities, and the capabilities (i.e. tasks) and resources (i.e.
devices and applications) it has to achieve them. Different role types have exclusive skills.
For instance, only device controllers can communicate with devices, and the group leaders
have the power to impose certain goals to the members of their groups. The current version
of the architecture includes several predefined role types, but this list can be extended to
address new needs of sensor networks, such as secure communications or resource
assignment (Tubaishat, M. & Madria, S. 2003). These roles are played by actors, which are
agents with common inherited capabilities about goal management and task execution.
Their specification focuses on how they implement the specific tasks related with their roles.
The architecture defines teams of roles and their interactions to perform certain tasks, for
instance, the setup or the dynamic addition of sensors.
The previous definitions of sensor, roles and agent partially match those of INGENIAS
external applications, roles, and agents. Nevertheless there are relevant differences. For
instance, INGENIAS external applications and sensors are both environment elements
characterized in terms of offered methods and produced events, but sensors extend
applications considering its internal state, and how this changes as a consequence of
external events and method execution. Thus, this research has modified the INGENIAS
metamodel to accommodate the new concepts and being able to use the INGENIAS tools.
2. Important
Although there are partial solutions for the design of sensor networks, their integration relies
on ad-hoc solutions requiring important development efforts. In order to provide an effective
way for their integration, this chapter proposes an architecture based on the multi-agent
system paradigm with a clear separation of concerns. The architecture considers sensors as
devices used by an upper layer of controller agents. Agents are organized according to roles
related to the different aspects to integrate, mainly sensor management, communication and
data processing. This organization largely isolates and decouples the data management from
the changing network, while encouraging reuse of solutions. The use of the architecture is
facilitated by a specific modelling language developed through meamodelling.
3. Agent development with INGENIAS
INGENIAS (Pavón et al., 2005) is a MDE methodology for the development of MAS. It
comprehends a specific modelling language, a software process and a support tool.
Following MDE principles, it defines its design modelling language with a metamodel. This
metamodel is the basis for the semi-automated development of its tool, and also guides the
definition of the activities of its software process.
MAS in INGENIAS are organizations of agents, which are intentional and social entities.
Agents use applications, which represent the environment and system facilities. The models

to specify these MAS describe their environment, agents and interactions, both from the
static and dynamic perspectives. The modelling language also includes a simple extension
mechanism for agents through inheritance relationships: a new sub-agent type inherits all
the features of its super-agent type, but it can also extend or constrain them. Table 1 shows
the main INGENIAS concepts used by our approach.
The support tool of the methodology is the INGENIAS Development Kit (IDK). It provides a
graphical environment for the specification of MAS design models. The tool can be extended
with modules. The standard distribution includes modules for documentation and code
generation based on templates. A template is a text file annotated with tags. These tags
indicate the places where information from models has to be injected to get a proper
instantiation. The instantiated template can describe, for instance, the code for an agent in a
framework, the documentation of its goals, or the configuration files for its deployment.
Engineers can use code components in models to attach specific code to entities. For
instance, if engineers want to generate nesC (Gay et al., 2003) code, they first need to
develop a template with the general description of an agent in that language; then the code
generation module reads the design models of the sensor network, and for each agent
appearing in them, it generates its specific code for nesC instantiating the template (i.e.
replacing the tags with information from the models that includes the code components).
Concept Meaning
Agent An active element with explicit goals able to initiate actions involving other elements.
Role A group of related goals and tasks. An agent playing a role adopts its goals and must
be able to perform its tasks.
Environment
application
An element of the environment. Agents/roles act on the environment using its actions
and receive information from the environment through its events.
Internal
application
A non-intentional component of the MAS. Agents/roles use it through its actions and
receive information from it through its events.
Goal An objective of an agent/role. Agents/roles try to satisfy their goals executing tasks.
The satisfaction or failure of a goal depends on the presence or absence of some
elements (i.e. frame facts and events) in the society or the environment.
Task A capability of an agent/role. In order to execute a task, certain elements (i.e. frame
facts and events) must be available. The execution produces/consumes some
elements.
Interaction A basic communication action. Agents/roles send with them information to other
agents/roles.
Method A basic imperative operation of an application described by its parameters and result.
Frame fact An information element produced by a task, and therefore by the agents/roles.
Event An information element spontaneously produced by an application.
Interaction Any kind of social activity involving several agents/roles.
Group A set of agents/roles that share some common goals and the applications they have
access to. The behaviour of groups is specified with workflows involving its
components. These workflows indicate their tasks, the elements these
produce/consume and the agents/roles that carry them out. The workflows must
fulfil the group goals through the achievement of the individual agent/role goals.
Society A set of agents, roles, applications and groups, along with general rules that govern
their behaviour.
Environment The set of external applications with which the components of a MAS interact.
Table 1. Main concepts of the modelling language of the INGENIAS methodology.

28
There are two main reasons for the choice of INGENIAS in this work considering available
alternatives with agents (Vinyals et al., 2008). First, its modelling language is a suitable basis
for the extensions required for sensor networks. It considers concepts such as agents, roles
and environment applications that are required in our architecture, and covers the
interactions between system components with a high-level of detail. Second, INGENIAS
strictly adheres to MDE principles. It defines its modelling language with a metamodel that
is also the basis of the IDK development. This facilitates the modification of the language to
house additional concepts and propagating these changes to the tool. Given the complexity
of the development of sensor networks (Tubaishat, M. & Madria, S. 2003; Yick et al., 2008),
the availability of support tools (e.g. for coding, debugging or reporting) is mandatory to get
a high productivity. Nevertheless, the IDK has the shortcoming of using an ad-hoc approach
for transformations based on modules and templates, although there are ongoing efforts to
support more standard approaches (García Magariño et al., 2009). The development process
proposed in our work adopts standard transformation languages (Sendall et al., 2003) to
manipulate models and code. This has two key advantages. First, the tools to develop and
run these transformations are already externally available, so there is no need of new
developments. Second, these languages focus on the description of the transformations,
which facilitates their understanding as this is not blurred with low-level details about
processing design models (e.g. reading the input file, managing syntax errors or generating
the output file).
3.1 An agent-based modelling language
The design of MAS to manage sensor networks in the presented approach uses
specializations of general agent concepts. The purpose of these specializations is acting as a
guide for engineers: they indicate the concepts that should appear in the specifications and
how they are related. The main extensions of our approach to the INGENIAS (Pavón et al.,
2005) conceptual framework appear in Fig. 1. with their main relationships. The mechanism
used for the metamodel extension is its direct modification (Cook, S., 2000). Note that
profiles cannot be used since this is not an UML extension, and INGENIAS limits
inheritance to agents.
Fig. 1. represents elements of the metamodel of the modelling language in our approach.
Nodes and links respectively represent meta-entities and meta-relationships. Meta-
relationships with triangles and diamonds are standard (i.e. non specific of INGENIAS)
representations of inheritance and aggregation (i.e. whole-part link) relationships. Numbers
in the ends of relationships are cardinality indications. The stereotypes of nodes
(represented between angle brackets) are the names of the INGENIAS meta-entities that our
meta-entities extend. The meta-entities have the features (e.g. attributes and relationships) of
the extended meta-entities and add new features and constraints. For instance, at the meta-
modelling level, there are meta-entities device and controller that are modifications of the
INGENIAS meta-entities environment application and role respectively. These meta-entities
are related with a meta-relationship WFUses, which is restricted to connect this pair of meta-
entities. These meta-elements are instantiated in models. For example, a model can contain
instances of the device meta-entity, which can only be related with instances of the
controller meta-entity through instances of the WFUses meta-relationship. The rest of the
section discusses the concepts present in Fig. 1.
A sensor network in the proposed architecture distinguishes between reactive and active
components. Reactive components receive requests or notifications of events, and generate

Fig. 1. Partial metamodel of agent-based concepts for sensor networks.

30
answers for them that only depend on the input and some internal state if this exists. Active
components take initiatives on their own that contribute to satisfy the system goals. The
basic type of reactive component is the resource, and the actor of active component. Actors
are a specific type of agents that use resources. Their work is organized through the roles
they played. Roles represent prototypical aspects of the activities in the network. A role
indicates the goals it pursues and the available elements to achieve them, which can be
information, capabilities and resources.
A resource is an external application. Its specification is known, but neither its behaviour nor
its interfaces can be modified. The only way to interact with it is what their external/public
interfaces allow. The actions available for this external manipulation of resources are
represented by external methods. These methods can change the internal state of the resource,
i.e. modification method, or just consult it, i.e. consult method. Internal methods can be used to
provide information about the internal behaviour of the resource with specification
purposes, but other components of the MAS cannot invoke them. A resource may have
functioning parameters that influence its behaviour. These parameters can determine for
instance, the threshold of certain operations or the initially available energy. Resources
represent different elements appearing in sensor networks. A utility is a stateless resource. It
corresponds to a computational facility available for the network, such as data
normalization, combination of different signals or information conversions. Devices are
stateful resources able to generate events called notifications. The state is characterized in
terms of frame facts, which are the units of information in INGENIAS. Devices offer specific
methods to manage the subscription of other components to their notifications. A subclass
of devices is sensors, which generate events but are also able to perceive them in the
surrounding environment. Thus, the behaviour of a sensor is characterized in terms of a
state machine that changes its state according to the execution of methods and the
appearance of events from the environment. A channel is a particular type of sensor intended
for communication. It is able to send and receive information over a medium and perform
basic tests on it.
These resources are used by manager roles to provide services in sensor networks. The
language distinguishes two types of managers depending on if they work with devices or
utilities.
The controller is the role with access to devices. According to the rights it has over it, there
are two types of controllers. A passive controller can only consult the device state with consult
methods and perceive those events to which it subscribes. The active controller is able to
make requests to change the device state using its modification methods. In this way,
several access levels can be granted to controllers of the same devices.
The expert is the role in charge of utilities. This role specifies the knowledge and skills
required to manipulate an utility, as well as how to obtain additional information that can
be extracted from sequences of data manipulations over time. For instance, an expert can
store information about temporal series of signals to draw conclusions about trends.
Another concept central in the proposed solution is that of team. A team is a hierarchical
INGENIAS group that comprehends a leader role and several member roles. The leader has
the right of posing new commands to the members of its team, where a command is a kind of
objective. Roles receiving the commands must include them in their agenda, but their
management of them depends on their design. The leader can be also the provider of a
given service for all the members of its team. Teams facilitate setting up basic groups of
collaborating roles. For instance, there are groups for the initialization of the network,

solving issues of quality of service, communications or data processing. These teams
constitute design blocks that can be reused in different specifications.
The previous roles are played by roles and actors. When a role plays another role, it adds the
features of that role to its own ones. The actors are agents with common skills for the
management of goals (e.g. decomposition, checking their state or removing when satisfied),
planning for their achievement (in terms of the available information, resources and
capabilities) and basic communications (both with agents and resources). When an actor
plays a role, it fulfils the standard behaviours specified by the role, that is, it implements its
capabilities, has actual access to its resources, and manipulates the related goals and
information. The actor can have additional elements beyond those of its roles. Note that an
actor manipulates all these elements globally. For instance, the satisfaction of a goal linked
to a certain role can be the result of the information produced with a capability related with
another role.
The previous elements run in containers, which represent deployable computational devices.
A container has basic processing capabilities that allow the execution of agents, and at least
one channel for communication. Additionally, it can include an arbitrary number of
resources. Note that, given the relationships and constraints in the metamodel, a device and
its managers run in the same container.
In order to provide a simple extension mechanism for the language, this approach also
generalizes the INGENIAS inheritance relationship. It is not constrained to agents but can be
applied to any concept with an equivalent meaning: a sub-concept inheriting from a super-
concept has all its features but it can extend or constrain them with additional models.
4. Architecture for sensor networks
The metamodel for sensor networks just defines the modelling primitives that can be used
when specifying these networks as MAS. However, it cannot specify how these elements
should interact to provide the expected functionality. The architecture provides this
information. This section focuses on its description through its main teams. The list is not
exhaustive, as more teams can be specified to address new needs. The description of teams
includes their purpose, and the characterization of their leader and member roles regarding
their responsibilities. Note that when talking about roles performing actions, it is really the
actors playing those roles that perform the actions, as roles are just functional abstractions.
The initialization team is aimed at setting up all the components of a container and providing
them with the initial information required for their proper functioning. Its team leader is the
initializer and its members play the role of targets of the initialization. The initializer creates
all the actors in its container and sends them the information about the managers they play.
Then, each manager receives a list of the assigned resources, and the notifications and
external methods it can use. If required, it can also obtain information to initialize the
resources. Besides, each manager receives information about all the teams it belongs to,
including the type of team, its leader and the role of that manager in it. Note that these
teams can involve roles whose actors are not running in the same container.
An information process team focuses on the generation of information from the data of
devices. Its team leader is a consumer for that information. It organizes the gathering and
processing of data. Team members play the role of providers of information and can be
passive controllers or experts. The activity of these teams can begin either with a request
from the customer or with a notification from a device. In the second case, a passive

32
controller provider captures an event raised by a device and notifies it to its consumer. From
this point forward, both scenarios are the same. The consumer may send additional requests
to its manager providers: to passive controllers in order to collect additional data; to experts
to further manipulate these data before their use. Note that with this approach, the
consumer itself can be regarded as a manager that provides services of a higher-level, as it
encapsulates the interactions with a group of resources and its managers.
Communication teams refine the INGENIAS communication schema, as they give further
details about how interactions are transmitted between different actors and roles. They
manage communication through channels. The communicator is both the team leader and the
active controller of the channel. The rest of the members of the team play the role customers
in the communication. All the customers in a communication team are able of direct
communication between them, but they need to ask its communicator for external
communication outside the team. These teams encapsulate the use of the communication
infrastructure and related algorithms, which makes transparent the communication
capabilities of other network elements from the design point of view. Engineers only need to
guarantee that each role or actor that needs to communicate belongs to a communication
team in order to have access to a communicator. In order to optimize communications (e.g.
latency or energy consumption) and perform message routing, communicators need to build
a rough map of the nearby communicators. Containers have a limited range of
communication, so some messages may need several hops to reach its final destination. To
build the map, a communicator broadcasts a request of information amongst other
communicators in range. Available communicators answer this request with information
about the features of their service, and take note of the sending communicator.
Load balancing teams are intended to keep the quality of service in the network. Sensor
networks face to several situations that can require their dynamic reconfiguration. Some of
them were outlined in the introduction, such as failure of sensors or communications, but
also sensors overloaded with requests or replacement of the failing customer for some data.
Although different, all these situations are solved through the collaboration of two sub-
teams. First, there is a failure notification team where a team leader referee controls a group of
team member watchers that can warn of potential failures in the behaviour of some observed
elements of the network. For instance, a controller can be the watcher of a sensor: when this
sensor depletes its energy, it does not longer answer the requests of its watcher, which raises
to its referee the information about the failure. The referee evaluates that information and if
it determines that there is need of acting, a repairer team begins working. A repairer team
has as leader a dispatcher governing a set of referees and initializers. When a dispatcher
receives the notification of a failure, it looks for some replacement. The replacement can be
obtained either asking other referees in the team for a component with similar features or
asking an initializer to create a new one if possible. For instance, in the case of failure of a
sensor, the replacement could be another sensor in a container near the location of the
original one, but if an expert is failing, a new one can be created and assigned to the utilities
of the original one. The dispatcher informs of the replacement to the involved referees,
which send to the initializers in their containers the information to update. For instance,
adjustments need to be made in the state of the replacement or the teams depending on it.
Note that any container must have running at least two teams. The initial setup requires one
initialization team, and integration with other elements of the network a communication
team. Executing these teams requires at least one actor which plays the initializer and
communicator roles.

The architecture involving these teams pursues satisfying three main objectives. First, it
facilitates the design of sensor networks decoupling the different responsibilities in roles
and teams. Second, it looks for networks that can semi-autonomously reconfigure
themselves to address new situations, a concept present in current research in autonomic
computing (Kephart, J. O. & Chess, D. M., 2000). Third, it achieves the extensibility of the
design of systems to control sensor networks through new teams.
5. Development process
In this chapter a simple model-driven development process customized is included to
develop the control system of sensor networks following the architecture in section 4. A
model-driven process focuses the development on design models. Engineers refine these
models from abstract representations to those models closer to the intended target platform,
and finally to code. The refinements are partially supported by automated transformations.
The process proposed in this approach is based on the software process of the INGENIAS
methodology (Pavón et al., 2005). It adds to the INGENIAS process several specific activities
aimed at identifying the elements required in a sensor network. These elements are those
defined in the modelling language and organized in the teams of the architecture. Fig. 2.
shows the resulting process. Activities 1-7 are specific of the current approach, while
activities 8-13 summarize INGENIAS activities. The process takes as input a previous
analysis of the data required as output of the network and the sensors able to provide them,
and produces as output the code of the control system for the sensor network.
The design of the network begins with activity 1. Engineers determine the containers of the
network, i.e. the computational devices able to execute code and transmit information.
These are usually the sensors, but also additional devices such as computers or
communication facilities can be considered here. This activity also identifies the resources:
the sensors that gather data from the environment; the utilities that represent services that
actors use to process data. The activity distinguishes the two aspects of the sensor, as
resource and container. Note that the modelling language provides different concepts for
these aspects, and therefore assign to them particular features that must be considered in the
design models. When these elements have been identified, engineers assign them
initialization and communication teams. As discussed in section 4, these teams are
mandatory for every container.
Decision 2 and activities 3-4 are intended to organize complex processing and integration of
data. According to the architecture, information process teams are responsible of these
activities. Engineers identify in decision 2 and activity 3 specific data that must be generated
in the network. For each group of data, activity 4 designs the corresponding team. First,
engineers discover the sensors that provide the source data. For each sensor, they must
assign at least one active controller and a passive one. The first one is required in the
initialization, and the second one to provide access to sensor data. Next, engineers must
identify the data transformations required to get the final information. Some of them are
achieved using utilities of the network. For these utilities, engineers assign an expert.
Finally, the team is composed by the passive controllers of the sensors and the experts of the
utilities playing the role of providers, and a customer to integrate and consume the
information. The identification of this kind of teams finishes when all the complex
calculation of data has a team assigned.

34
Fig. 2. Process for the development of sensor networks.
Decision 5 and activities 6-7 are intended to specify the teams that manage the dynamic
adaptation of the network. Engineers begin this design with decision 5, where they find out
what the elements are that can fail or be incrementally set up or deployed during the
working of the network. This identification considers resources, roles and actors. For every
element identified in this decision, activity 6 carries out an analysis regarding its potential
replacements, and how they can be located and evaluated to find the best suited if several
are available. Activity 7 designs the specific team related with this replacement. It includes a
watcher that monitors the element. In the case of a device it is a passive controller, for a
utility it is an expert, and for a role or agent it can be a customer that communicates with it.
The team also needs a referee that evaluates when the failure needs to be notified for a
potential replacement. The repairer team includes referees related with the same type of
elements and similar features. For instance, for sensors they can be referees of nearby
sensors and for roles other agents in the same container able to work with the same
resources. As an alternative, initializers can be used to set up new roles or agents in these
teams. Each of these teams must also identify its dispatcher, which selects the best
alternative for a required replacement.
After these activities, engineers have available PIM of the resulting system according to the
architecture. These PIM describe the devices, agents and roles, the information they

exchange, and their interactions; they do not contain details on the final target platform, for
instance about energy levels or low-level control commands for the sensors. Activities 8-13
follow the INGENIAS process to refine these models and generate the final code of the
control system.
Activity 8 adds several INGENIAS PIM to the MAS specifications. Organization models
define agents and groups outside the architecture, and assign to the groups workflows that
describe their work. This allows refining the teams when complex processing of data needs
further specification. Agent models refine actors and roles with additional goals, capabilities
and information. These models also establish the pieces of information whose appearance
determine when a goal is satisfied or failed. Tasks/Goals models map tasks with the goals
that satisfy them, and hierarchically decompose goals and tasks into sub-elements.
Interaction models describe actor interactions in terms of goals pursued, information
exchanged and tasks performed. These models provide the details of the previous
architectural design, though they are not always required. For instance, if engineers do not
need to refine teams beyond what is said in the architecture, they do not use organization
models.
Activity 9 and 10 develop the models required for the final target platform. Activity 10
develops the PM corresponding to the target platform. These PM include information about
how to translate general concepts to specific elements in the platform. As explained in
section 3, INGENIAS uses templates to represents PM. In case that these PM are available
from previous projects, activity 10 can be omitted. Activity 9 develops the PSM of a specific
design for the target platform. The PSM provide two main types of information. First,
resources include their functioning parameters for the target platform, which can describe
their limits about energy, memory or computational power. Second, engineers provide with
code components attached to modelling entities the code specific for them. That is, part of
the code required for the final system cannot be extracted from models, as models abstract
the specific low-level details of the behaviour of systems. For instance, there are not
modelling primitives to describe complex algorithms, and templates only contain general
code for concept types in a platform. Engineers can include the remaining information
attaching INGENIAS code components to the elements in models.
Activity 11 considers the development of the transformations that support the semi-
automated refinement of PIM to PSM in activity 12, and the generation of code from PSM in
activity 13. In the case of an INGENIAS development, transformations are implemented as
IDK modules. These modules support model transformations and model-to-text
transformations. Model transformations are useful to represents standard refinements of
model concepts. For instance, each actor needs several goals to manage its planning cycles
(e.g. collect information, discard non-achievable goals, look for achievable goals), but these
are standard and engineers do not need to write them for each actor; a transformation can
automatically generate these goals for the available actors. The best-known example of
model-to-text transformation is code generation. In this case, the IDK includes a module for
this purpose in its standard distribution. For a given specification and target platform, this
module operates as follows: (1) it identifies the templates for the concepts present in the
specifications and the target platform; (2) it traverses the templates looking for their tags; (3)
when it found a tag, it replaces the tag with information from the models, which can be the
content of a code template; (4) it returns the instantiated template as its output, which is the
code of the concepts. In this way, changing the target platform for a given design only

36
requires using different PM (i.e. code templates) and changing the attached code
components.
Note that though Fig. 2. shows a sequence of activities, a true development needs to carry
out several iterations of these activities. For instance, engineers can discover when they are
developing their PSM in activity 9 that some teams are missed, and they will need to return
to activities 2-7. Moreover, activities 1-7 need further refinement to provide more guidance
depending on specific application contexts.
6. Related work
This section compares the proposed approach with related work in sensor networks and
MAS. The introduction already discussed different perspectives on the design of sensor
networks. This section follows this classification and distinguishes between integral
solutions with architectures and partial solutions for specific aspects. Among architectures,
there are examples focused on the infrastructure and others on the high-level design of the
network. Transversal to these approaches, some researchers have proposed the use of MAS
for the development of the related control systems.
Architectures for sensor networks focused on infrastructure provide a platform with basic
services for the sensor network. This platform has a component model that those elements
to integrate in the network must fulfil. In this group can be included operating systems (e.g.
TinyOS (Hill et al., 2000) and Contiki (Dunkels et al., 2000)), programming languages (e.g.
nesC (Gay et al., 2003)) and middleware (e.g. MORE (Wolff et al., 2007), RUNES (Costa et al.,
2005), SMEPP (Caro-Benito et al., 2009) and Tenet (Gnawali et al., 2006)). These works and
ours appear at different levels of abstraction when considering the development of sensor
networks and their control systems. According to MDA (Kleppe et al., 2003), the models
based on the architecture proposed in this work are PIM that use highly abstract primitives
to model sensor networks. These abstract elements are mapped to the constructions
available in these implementation platforms. For instance, the concept of team in our
architecture can be partially supported in SMEPP (Caro-Benito et al., 2009) with the concept
of group, which provides mechanisms for authentication and authorization, communication
between agents can be implemented with μSOA messages of MORE (Wolff et al., 2007). The
information of these platforms would appear in our approach as PM. Engineers would
refine the PIM of our architecture in that provides the information for that specific
implementation. This refinement would be partly implemented with automated
transformations from PIM to PSM, for instance to create the structure of μSOA messages,
and partly manual, for instance the actual content of messages. If required, abstract
components of these architectures could appear in the architecture of this work as additional
roles and teams. The code generation module of the IDK would generate the code for the
control system from the final PSM and PM.
Architectures considering the high-level design of the network have adopted usually the
form of guidelines. Either they just give some abstract design principles or they consider
also a development process. From the point of view of the design principles, the flexibility of
the proposed architecture allows it adopting the principles underlying a variety of these
approaches. For instance, carrying out the processing of data as close as possible to their
sources (as (Qi et al., 2001) recommends) means that the actors playing the roles of
information process teams should run in the same container, and moving that processing to
more powerful computational devices (as proposed in (Gnawali et al., 2006)) splits these

actors in different containers. In both cases the design of roles and teams is the same, and
only the initialization information actually changes. The proposed architecture is not
intended however for mobile agents as those in (Qi et al., 2001; Tong et al., 2003). Actors in
the proposed architecture are not able of redeploying in a container different from that
where the initializers create them. However, the initializers could be modified to allow this
kind of behaviour. It would be enough to allow initializers to collect information about the
actor that wants to migrate (e.g. current state, teams or available resources), and send it to
the target container where another initializer would use it to create another actor with the
same data. Of course, this migration would also demand checking that the resources and
managers that the actor needs are available in the target container.
This section has already mentioned works based on agents (Botti et al., 1999; Hla et al., 2008;
Jamont, J. P. & Occello, M., 2007; Pavón et al., 2007; Qi et al., 2001), but some of them deserve
further discussion given the similarities with our work. (Hla et al., 2008) establishes some
guides for the design of MAS for sensor networks and uses some concepts common with
our approach, as controllers, sensors and providers. They also consider concepts that our
approach can incorporate, such as directory facilitators to refine the location of sensors with
certain features. However, these roles are informally defined in terms of their
responsibilities and the set is closed. In this sense, our approach with a specific modelling
language and the possibility of defining teams facilitates customization. Besides, (Hla et al.,
2008) does not consider a development process for control systems. (Botti et al., 1999;
Jamont, J. P. & Occello, M., 2007; Pavón et al., 2007) present development process for control
systems. ARTIS (Botti et al., 1999) is a methodology for holonic manufacturing systems that
includes the use of sensors. It considers aspects of real time, but ignores issues such as
limited resources. (Jamont, J. P. & Occello, M., 2007) is tailored for sensor networks and has
been validated with real projects. Though it considers automated generation of code, it does
not offer a standard process for it, as our approach does with MDE. This makes more
difficult reusing available infrastructure for development and reusing the design models of
previous projects. (Pavón et al., 2007) deserves special mention as it also considers
INGENIAS for the design of sensor networks. As a matter of fact, both approaches represent
complementary points of view. The approach proposed in this work extends the modelling
language of INGENIAS with new concepts, and establishes patterns and guidelines to
address the design of these networks with its architecture. These tasks correspond to
activities 1-7 in Fig. 2. Since these models are INGENIAS models, their refinement to the
running code can follow any suitable INGENIAS development process. These tasks
correspond to activities 8-13 in Fig. 2. In particular, this refinement can follow (Pavón et al.,
2007), which is targeted for sensor networks. Thus, these works can be seen as part of an
ongoing effort to provide engineers with a tailored methodology and development process
for sensor networks.
7. Conclusions
The presented approach is intended to facilitate the high-level design of sensor networks
based on MAS. It includes an agent-oriented modelling language with specific extensions
and an architecture describing how these elements interact to achieve the standard
functionalities of these networks.
The modelling language is built around three main concepts. Resources are the passive
elements in the network. They are modelled in terms of their available methods. Their sub-

38
types include sensors and data processing utilities. Sensors add to resources a state and
work with events, both perceived from their environment and raised to inform to their
controllers. These abstractions cover the most common uses of sensors in previous works.
The active elements of the network are designed as roles. Roles are common abstraction in
MAS defined in terms of their goals, capabilities to achieve them, and their resources and
information. Managers are in our approach the roles governing resources. They can have
different access rights in order to organize the use of the resources. The final element of the
language is teams, which are hierarchical groups of roles aimed at performing some
collaborative activities in the network. Actors running in containers implement the roles.
The architecture works with these concepts to specify teams that define standard aspects of
behaviour in these networks. It identifies teams for the initialization or redeployment of
containers, the management of data (including collection, processing and integration),
communications and load balancing (or adaptation of the network to changes in the
environment or its elements).
The proposed solution is intended to be flexible in several ways. First, it allows
accommodating new or modified concepts for specific needs through changes in its
metamodel. Using model-driven techniques, engineers propagate these changes to the
supporting tools. Second, the specialization of concepts with inheritance relationships and
the organization of systems around teams cover a variety of approaches, so it allows
incorporating existing research in the area. Third, the use of a MDE approach facilitates
reusing the knowledge present in the definition of teams. These teams can become the basic
building blocks for sensor networks with MAS, as their models can incorporate information
for the final code generation. Only models and transformations related with the control of
specific sensors and particular manipulations of data need to be replaced in the system. If
new teams were required, they could be modelled as extensions of concepts presents in the
architecture as done with standard teams.
The main concern in the application of the proposed approach is the difficulty to model the
low-level details of sensor networks, such as energy consumption of routing algorithms for
messages. At the moment, the only mean to do that is attaching code snippets to entities in
design models for the code generation. There are plans to extend the modelling language
with additional primitives to describe some low level issues. For instance, methods can be
modelled with additional state machines, and certain standard data transformations can be
added as instances of the methods of utilities. Moreover, this work has applied the standard
INGENIAS development process for part of its process.
8. References
Akyildiz, I. F., Melodia, T., Chowdhury, K. R. (2007) A survey on wireless multimedia
sensor networks. Computer Networks 51(4), pp. 921-960.
Baronti, P., Pillai, P., Chook, V. W. C., Chessa, S., Gotta, A., Hu, Y. F. (2007) Wireless sensor
networks: A survey on the state of the art and the 802.15. 4 and ZigBee standards.
Computer Communications 30(7), pp. 1655-1695.
Botti, V., Carrascosa, C., Julián, V., Soler, J. (1999) Modelling agents in hard real-time
environments. In Proceedings of the 9th European Workshop on Modelling
Autonomous Agents in a Multi-Agent World (MAAMAW’99), Lecture Notes in
Computer Science 1647, pp. 63-76.
Budinsky, F. (2003) Eclipse Modelling Framework: Developer’s Guide. Addison Wesley.

Caro-Benito, R. J., Garrido-Márquez, D., Plaza-Tron, P., Román-Castro, R., Sanz-Martín, N.,
Serrano-Martín, J. L. (2009) SMEPP: A Secure Middleware For Embedded P2P. In
Proceedings of the 2009 ICT Mobile Summit, pp. 1-8.
Casbeer, D. W., Kingston, D. B., Beard, R. W., McLain, T. W. (2006) Cooperative forest fire
surveillance using a team of small unmanned air vehicles. International Journal of
Systems Science 37(6), pp. 351-360.
Cook, S. (2000) The UML family: Profiles, prefaces and packages. In Proceedings of the 3rd
International Conference «UML» – The Unified Modelling Language (UML 2000),
Lecture Notes in Computer Science 1939, pp. 255-264.
Costa, P., Coulson, G., Mascolo, C., Picco, G. P., Zachariadis, S. (2005) The RUNES
middleware: A reconfigurable component-based approach to networked embedded
systems. In Proceedings of the 16th Annual IEEE International Symposium on
Personal Indoor and Mobile Radio Communications (PIMRC’05), vol. 2, pp. 806-
810.
Dunkels, A., Gronvall, B., Voigt, T. (2004) Contiki - A Lightweight and Flexible Operating
System for Tiny Networked Sensors. In Proceedings of the 29th Annual IEEE
International Conference on Local Computer Networks (LCN 2004), pp. 452-462.
Estrin, D., Govindan, R., Heidemann, J., Kumar, S. (1999) Next century challenges: Scalable
coordination in sensor networks. In Proceedings of the 5th Annual ACM/IEEE
International Conference on Mobile Computing and Networking (MOBICOM
1999), pp. 263-270.
Gay, D., Levis, P., Von Behren, R., Welsh, M., Brewer, E., Culler, D. (2003) The nesC
language: A holistic approach to networked embedded systems. In Proceedings of
the ACM SIGPLAN 2003 Conference on Programming Language Design and
Implementation (PLDI 2003), pp. 1-11.
Gnawali, O., Jang, K. Y., Paek, J., Vieira, M., Govindan, R., Greenstein, B., Joki, A., Estrin, D.,
Kohler, E. (2006) The Tenet architecture for tiered sensor networks. In Proceedings
of the 4th International Conference on Embedded Networked Sensor Systems
(SenSys 2006), ACM Press, pp. 153-166.
Hill, J., Szewczyk, R., Woo, A., Hollar, S., Culler, D., Pister, K. (2000) System architecture
directions for networked sensors. ACM Sigplan Notices 35(11), pp. 93-104.
Hla, K. H. S., Choi, Y., Park, J. S. (2008) The multi agent system solutions for wireless sensor
network applications. In Proceedings of the 2nd KES Symposium on Agent and
Multi-Agent Systems – Technologies and Applications (KES-AMSTA 2008), Lecture
Notes in Computer Science 4953, pp. 454-463.
Jamont, J. P., Occello, M. (2007) Designing embedded collective systems: The DIAMOND
multiagent method. In Proceedings of the 19th IEEE International Conference on
Tools with Artificial Intelligence (ICTAI 2007), pp. 91-94.
Kephart, J. O., Chess, D. M. (2003) The Vision of Autonomic Computing. Computer 36(1),
pp. 41-50.
Kleppe, A. G., Warmer, J., Bast, B. (2003) MDA Explained: The Model Driven Architecture -
Practice and Promise. Addison-Wesley.
García-Magariño, I., Rougemaille, S., Fuentes-Fernández, R., Migeon, F., Gleizes, M. P.,
Gómez-Sanz, J. J. (2009) A Tool for Generating Model Transformations By-Example
in Multi-Agent Systems. In Proceedings of the 7th International Conference on

40
Practical Applications of Agents and Multi-Agent Systems (PAAMS 2009),
Advances in Soft Computing 55, pp. 70-79.
Lorincz, K., Malan, D. J., Fulford-Jones, T. R. F., Nawoj, A., Clavel, A., Shnayder, V.,
Mainland, G., Welsh, M., Moulton, S. (2004) Sensor Networks for Emergency
Response: Challenges and Opportunities. IEEE Pervasive Computing 3(4), pp. 16-
23.
Object Management Group (OMG) (2006) Meta Object Facility (MOF), Core Specification,
Version 2.0. January 2006, http://www.omg.org
Object Management Group (OMG) (2009) OMG Unified Modeling Language (OMG UML),
Superstructure, V2.2. February 2009, http://www.omg.org
Pavón, J., Gómez-Sanz, J., Fernández-Caballero, A., Valencia-Jiménez, J. J. (2007)
Development of intelligent multisensor surveillance systems with agents. Robotics
and Autonomous Systems 55(12), pp. 892-903.
Pavón, J., Gómez-Sanz, J. J., Fuentes, R. (2005). The INGENIAS Methodology and Tools. In
Henderson-Sellers, B., Giorgini, P. (eds.). Agent-Oriented Methodologies, Idea
Group Publishing, chapter IX, pp. 236–276.
Qi, H., Iyengar, S. S., Chakrabarty, K. (2001) Multiresolution data integration using mobile
agents in distributed sensor networks. IEEE Transactions on Systems, Man, and
Cybernetics, Part C: Applications and Reviews 31(3), pp. 383-391.
Schmidt, D. C. (2006) Model-Driven Engineering. IEEE Computer 39(2), pp. 25-31.
Sendall, S., Kozaczynski, W. (2003) Model Transformation: The Heart and Soul of Model-
Driven Software Development. IEEE Software 20(5), pp. 42-45.
Son, B., Her, Y., Kim, J. G. (2006) A design and implementation of forest-fires surveillance
system based on wireless sensor networks for South Korea mountains.
International Journal of Computer Science and Network Security 6(9B), pp. 124-130.
Tong, L., Zhao, Q., Adireddy, S. (2003) Sensor networks with mobile agents. In Proceedings
of the IEEE Military Communications Conference (MILCOM 2003), vol. 1, pp. 688-
693.
Tubaishat, M., Madria, S. (2003) Sensor networks: an overview. IEEE Potentials 22(2), pp. 20-
23.
Vinyals, M., Rodriguez-Aguilar, J. A., Cerquides, J. (2008) A survey on sensor networks from
a multi-agent perspective. In Proceedings of the 2nd International Workshop on
Agent Technology for Sensor Networks (ATSN 2008), pp. 1-8.
Weiss, G. (ed.) (2000) Multiagent Systems: A Modern Approach to Distributed Artificial
Intelligence. MIT Press.
Wolff, A., Michaelis, S., Schmutzler, J., Wietfeld, C. (2007) Network-centric Middleware for
Service Oriented Architectures across Heterogeneous Embedded Systems. In
Proceedings of the 11th International IEEE Enterprise Distributed Object
Computing Conference (EDOC 2007), Middleware for Web Services Workshop, pp.
105-108.
Yick, J., Mukherjee, B., Ghosal, D. (2008) Wireless sensor network survey. Computer
Networks 52(12), pp. 2292-2330.

Another Random Scribd Document
with Unrelated Content

was bad enough for the poor little dreamer of dreams, but
worse was to follow.
Mrs Willis did not speak to Hester, but she did stop for an
instant beside Annie Forest. Hester saw her lay her white
hand on the young girl’s shoulder and whisper for an instant
in her ear. Annie’s lovely gipsy face flushed a vivid crimson.
“For your sake, darling,” she whispered back; but Hester
caught the words, and was consumed by a fierce jealousy.
The girls went into the school-room, where Mdlle. Perier
gave a French lesson to the upper class. Hester belonged to
no class at present, and could look around her, and have
plenty of time to reflect on her own miseries, and
particularly on what she now considered the favouritism
shown by Mrs Willis.
“Mr Everard at least will read through that girl,” she said to
herself; “he could not possibly endure any one so loud. Yes,
I am sure that my only friend at home, Cecilia Day, would
call Annie very loud. I wonder Mrs Willis can endure her. Mrs
Willis seems so ladylike herself, but—Oh, I beg your pardon,
what’s the matter?”
A very sharp voice had addressed itself to the idle Hester.
“But, mademoiselle, you are doing nothing! This cannot for
a moment be permitted. Pardonnez-moi, you know not the
French? Here is a little easy lesson. Study it, mademoiselle,
and don’t let your eyes wander a moment from the page.”
Hester favoured Mdlle. Perier with a look of lofty contempt,
but she received the well-thumbed lesson-book in absolute
silence.

At eight o’clock came breakfast, which was nicely served,
and was very good and abundant. Hester was thoroughly
hungry this morning, and did not feel so shy as the night
before. She found herself seated between two strange girls,
who talked to her a little and would have made themselves
friendly had she at all encouraged them to do so. After
breakfast came half an hour’s recreation, when, the
weather being very bad, the girls again assembled in the
cosy play-room. Hester looked round eagerly for Cecil
Temple, who greeted her with a kind smile, but did not ask
her into her inclosure. Annie Forest was not present, and
Hester breathed a sigh of relief at her absence. The half-
hour devoted to recreation proved rather dull to the
newcomer. Hester could not understand her present world.
To the girl who had been brought up practically as an only
child in the warm shelter of a home, the ways and doings of
school-girl life were an absolute enigma.
Hester had no idea of unbending or of making herself
agreeable. The girls voted her to one another stiff and
tiresome, and quickly left her to her own devices. She
looked longingly at Cecil Temple; but Cecil, who could never
be knowingly unkind to any one, was seizing the precious
moments to write a letter to her father, and Hester
presently wandered down the room and tried to take an
interest in the little ones. From twelve to fifteen quite little
children were in the school, and Hester wondered with a
sort of vague half-pain if she might see any child among the
group the least like Nan.
“They will like to have me with them,” she said to herself.
“Poor little dots, they always like big girls to notice them,
and didn’t they make a fuss about Miss Forest last night!
Well, Nan is fond enough of me, and little children find out
so quickly what one is really like.”

Hester walked boldly into the group. The little dots were all
as busy as bees, were not the least lonely, or the least shy,
and very plainly gave the intruder to understand that they
would prefer her room to her company. Hester was not
proud with little children—she loved them dearly. Some of
the smaller ones in question were beautiful little creatures,
and her heart warmed to them for Nan’s sake. She could
not stoop to conciliate the older girls, but she could make
an effort with the babies. She knelt on the floor and took up
a headless doll.
“I know a little girl who had a doll like that,” she said.
Here she paused and several pairs of eyes were fixed on
her.
“Poor dolly’s b’oke,” said the owner of the headless one in a
tone of deep commiseration.
“You are such a breaker, you know, Annie,” said Annie’s little
five-year-old sister.
“Please tell us about the little girl what had the doll wifout
the head,” she proceeded, glancing at Hester.
“Oh, it was taken to a hospital, and got back its head,” said
Hester quite cheerfully; “it became quite well again, and
was a more beautiful doll than ever.”
This announcement caused intense wonder and was
certainly carrying the interest of all the little ones. Hester
was deciding that the child who possessed the headless doll
had a look of Nan about her dark brown eyes, when
suddenly there was a diversion—the play-room door was
opened noisily, banged-to with a very loud report, and a
gay voice sang out—

“The fairy queen has just paid me a visit. Who wants
sweeties from the fairy queen?”
Instantly all the little feet had scrambled to the
perpendicular, each pair of hands was clapped noisily, each
little throat shouted a joyful—
“Here comes Annie!”
Annie Forest was surrounded, and Hester knelt alone on the
hearth-rug.
She felt herself colouring painfully—she did not fail to
observe that two laughing eyes had fixed themselves with a
momentary triumph on her face; then, snatching up a book,
which happened to lie close, she seated herself with her
back to all the girls, and her head bent over the page. It is
quite doubtful whether she saw any of the words, but she
was at least determined not to cry.
The half-hour so wearisome to poor Hester came to an end,
and the girls, conducted by Miss Danesbury, filed into the
school-room and took their places in the different classes.
Work had now begun in serious earnest. The school-room
presented an animated and busy scene. The young faces
with their varying expressions betokened on the whole the
preponderance of an earnest spirit. Discipline, not too
severe, reigned triumphant.
Hester was not yet appointed to any place among these
busy workers, but while she stood wondering, a little
confused, and half intending to drop into an empty seat
which happened to be close, Miss Danesbury came up to
her.

“Follow me, Miss Thornton,” she said, and she conducted
the young girl up the whole length of the great school-
room, and pushed aside some baize curtains which
concealed a second smaller room, where Mrs Willis sat
before a desk.
The head-mistress was no longer dressed in soft pearl-grey
and Mechlin lace. She wore a black silk dress, and her white
cap seemed to Hester to add a severe tone to her features.
She neither shook hands with the new pupil nor kissed her,
but said instantly in a bright though authoritative tone—
“I must now find out as quickly as possible what you know,
Hester, in order to place you in the most suitable class.”
Hester was a clever girl, and passed through the ordeal of a
rather stiff examination with considerable ability. Mrs Willis
pronounced her English and general information quite up to
the usual standard for girls of her age—her French was
deficient, but she showed some talent for German.
“On the whole I am pleased with your general intelligence,
and I think you have good capacities, Hester,” she said in
conclusion. “I shall ask Miss Good, our very accomplished
English teacher, to place you in the third-class. You will have
to work very hard, however, at your French, to maintain
your place there. But Mdlle. Perier is kind and painstaking,
and it rests with yourself to quickly acquire a conversational
acquaintance with the language. You are aware that, except
during recreation, you are never allowed to speak in any
other tongue. Now, go back to the school-room, my dear.”
As Mrs Willis spoke she laid her finger on a little silver gong
which stood by her side.
“One moment, please,” said Hester, colouring crimson, “I
want to ask you a question, please.”

“Is it about your lessons?”
“No—oh, no; it is—”
“Then pardon me, my dear,” uttered the governess, “I sit in
my room every evening from eight to half-past, and I am
then at liberty to see a pupil on any subject which is not
trifling. Nothing but lessons are spoken of in lesson hours,
Hester. Ah, here comes Miss Good. Miss Good, I should wish
you to place Hester Thornton in the third-class. Her English
is up to the average. I will see Mdlle. Perier about her at
twelve o’clock.”
Hester followed the English teacher into the great school-
room, took her place in the third-class, at the desk which
was pointed out to her, was given a pile of new books, and
was asked to attend to the history lesson which was then
going on.
Notwithstanding her confusion, a certain sense of soreness,
and some indignation at what she considered Mrs Willis’s
altered manner, she acquitted herself with considerable
spirit, and was pleased to see that her class companions
regarded her with some respect.
An English literature lecture followed the history, and here
again Hester acquitted herself with éclat. The subject to-day
was “Julius Caesar,” and Hester had read Shakespeare’s
play over many times with her mother.
But when the hour came for foreign languages, her brief
triumph ceased. Lower and lower did she fall in her school-
fellows’ estimation, as she stumbled through her truly
English-French. Mdlle. Perier, who was a very fiery little
woman, almost screamed at her—the girls coloured and
nearly tittered. Hester hoped to recover her lost laurels in
German, but by this time her head ached, and she did very

little better in the German which she loved than in the
French which she detested. At twelve o’clock she was
relieved to find that school was over for the present, and
she heard the English teacher’s voice desiring the girls to go
quickly to their rooms, and to assemble in five minutes’
time in the great stone hall, equipped for their walk.
The walk lasted for a little over an hour, and was a very
dreary penance to poor Hester, as she was neither allowed
to run, race, nor talk a word of English. She sighed heavily
once or twice, and several of the girls who looked at her
curiously agreed with Annie Forest that she was decidedly
sulky. The walk was followed by dinner; then came half an
hour of recreation in the delightful play-room, and eager
chattering in the English tongue.
At three o’clock the school assembled once more; but now
the studies were of a less severe character, and Hester
spent one of her first happy half-hours over a drawing
lesson. She had a great love for drawing, and felt some
pride in the really beautiful copy which she was making of
the stump of an old gnarled oak-tree. Her dismay, however,
was proportionately great when the drawing-master drew
his pencil right across her copy.
“I particularly requested you not to sketch in any of the
shadows, Miss Thornton. Did you not hear me say that my
lesson to-day was in outline? I gave you a shaded piece to
copy in outline—did you not understand?”
“This is my first day at school,” whispered back poor Hester,
speaking in English in her distress. Whereupon the master
smiled, and even forgot to report her for her transgression
of the French tongue.

Hester spent the rest of that afternoon over her music
lesson. The music-master was an irascible little German, but
Hester played with some taste, and was therefore not too
severely rapped over the knuckles.
Then came tea and another half-hour of recreation, which
was followed by two silent hours in the school-room, each
girl bent busily over her books in preparation for the next
day’s work. Hester studied hard, for she had made up her
mind to be the intellectual prodigy of the school. Even on
this first day, miserable as it was, she had won a few
plaudits for her quickness and powers of observation. How
much better could she work when she had really fallen into
the tone of the school, and understood the lessons which
she was now so carefully preparing! During her busy day
she had failed to notice one thing: namely, the absence of
Annie Forest. Annie had not been in the school-room, had
not been in the play-room; but now, as the clock struck
eight, she entered the school-room with a listless
expression, and took her place in the same class with
Hester. Her eyes were heavy, as if she had been crying, and
when a companion touched her, and gave her a
sympathising glance, she shook her head with a sorrowful
gesture, but did not speak. Glasses of milk and slices of
bread and butler were now handed round to the girls, and
Miss Danesbury asked if any one would like to see Mrs Willis
before prayers. Hester half sprang to her feet, but then sat
down again. Mrs Willis had annoyed her by refusing to
break her rules and answer her question during lesson
hours. No, the silly child resolved that she would not trouble
Mrs Willis now.
“No one to-night, then?” said Miss Danesbury, who had
noticed Hester’s movement.
Suddenly Annie Forest sprang to her feet.

“I’m going, Miss Danesbury,” she said. “You need not show
me the way; I can find it alone.”
With her short, curly hair falling about her face, she ran out
of the room.

Chapter Eight.
“You Have Woken Me Too Soon.”
When Hester reached her bedroom after prayers on that
second evening, she was dismayed to find that she no
longer could consider the pretty little bedroom her own. It
had not only an occupant, but an occupant who had left
untidy traces of her presence on the floor, for a stocking lay
in one direction and a muddy boot sprawled in another. The
newcomer had herself got into bed, where she lay with a
quantity of red hair tossed about on the pillow, and a heavy
freckled face turned upward, with the eyes shut and the
mouth slightly open.
As Hester entered the room, from these parted lips came
unmistakable and loud snores. She stood still dismayed.
“How terrible!” she said to herself—“oh, what a girl! and I
cannot sleep in the room with any one who snores—I really
cannot!”
She stood perfectly still, with her hands clasped before her,
and her eyes fixed with almost ludicrous dismay on this
unexpected trial. As she gazed, a fresh discovery caused
her to utter an exclamation of horror aloud.
The newcomer had curled herself up comfortably in her bed.
Suddenly, to her surprise, a voice said very quietly, without
a flicker of expression coming over the calm face, or the
eyes even making an effort to open—
“Are you my new school-mate?”
“Yes,” said Hester, “I am sorry to say I am.”

“Oh, don’t be sorry, there’s a good creature; there’s nothing
to be sorry about. I’ll stop snoring when I turn on my side—
it’s all right. I always snore for half an hour to rest my back,
and the time is nearly up. Don’t trouble me to open my
eyes, I am not the least curious to see you. You have a
cross voice, but you’ll get used to me after a bit.”
“But you’re in my bed,” said Hester. “Will you please to get
into your own?”
“Oh, no, don’t ask me; I like your bed best. I slept in it the
whole of last term. I changed the sheets myself, so it does
not matter. Do you mind putting my muddy boots outside
the door, and folding up my stockings? I forgot them, and I
shall have a bad mark if Danesbury comes in. Good-night—
I’m turning on my side—I won’t snore any more.”
The heavy face was now only seen in profile, and Hester,
knowing that Miss Danesbury would soon appear to put out
the candle, had to hurry into the other bed as fast as she
could; something impelled her, however, to take up the
muddy boots with two very gingerly fingers, and place them
outside the door.
She slept better this second night, and was not quite so
startled the next morning when the remorseless gong
aroused her from slumber. The maid-servant came in as
usual to light the candles, and to place two cans of hot
water by the two wash-handstands.
“You are awake, miss?” she said to Hester.
“Oh, yes,” replied Hester almost cheerfully.
“Well, that’s all right,” said the servant. “Now I must try and
rouse Miss Drummond, and she always takes a deal of
waking; and if you don’t mind, miss, it will be an act of

kindness to call out to her in the middle of your own
dressing—that is, if I don’t wake her effectual.”
With these words, the housemaid approached the bed
where the red-haired girl lay again on her back, and again
snoring loudly.
“Miss Drummond, wake, miss; it’s half-past six. Wake up,
miss—I have brought your hot water.”
“Eh?—what?” said the voice in the bed sleepily; “don’t
bother me, Hannah—I—I’ve determined not to ride this
morning; go away—” then more sleepily, and in a lower key,
“Tell Percy he can’t bring the dogs in here.”
“I ain’t neither your Hannah, nor your Percy, nor one of the
dogs,” replied the rather irate Alice—“There, get up, miss,
do. I never see such a young lady for sleeping, never.”
“I won’t be bothered,” said the occupant of the bed, and
now she turned deliberately on her side and snored more
loudly than ever.
“There’s no help for it,” said Alice: “I have to do it nearly
every morning, so don’t you be startled, miss. Poor thing,
she would never have a good conduct mark but for me. Now
then, here goes. You needn’t be frightened, miss—she don’t
mind it the least bit in the world.”
Here Alice seized a rough Turkish towel, placed it under the
sleepy head with its shock of red hair, and, dipping a
sponge in a basin of icy cold water, dashed it on the white
face.
This remedy proved effectual; two large pale blue eyes
opened wide, a voice said in a tranquil and unmoved tone—

“Oh, thank you, Alice. So I’m back at this horrid, detestable
school again?”
“Get your feet well on the carpet, Miss Drummond, before
you falls off again,” said the servant. “Now then, you’d
better get dressed as fast as possible, miss—you have lost
five minutes already.”
Hester, who had laughed immoderately during this little
scene, was already up and going through the processes of
her toilet. Miss Drummond, seated on the edge of her bed,
regarded her with sleepy eyes.
“So you are my new room-mate?” she said—“What’s your
name?”
“Hester Thornton,” replied Hetty with dignity.
“Oh—I’m Susy Drummond—you may call me Susy if you
like.”
Hester made no response to this gracious invitation.
Miss Drummond sat motionless, gazing down at her toes.
“Had not you better get dressed?” said Hester after a long
pause, for she really feared the young lady would fall asleep
where she was sitting.
Miss Drummond started.
“Dressed! So I will, dear creature. Have the sweet goodness
to hand me my clothes.”
“Where are they?” asked Hester rather crossly, for she did
not care to act as lady’s-maid.

“They are over there, on a chair, in that lovely heap with a
shawl flung over them. There, toss them this way—I’ll get
into them somehow.”
Miss Drummond did manage to get into her garments; but
her whole appearance was so heavy and untidy when she
was dressed, that Hester by the very force of contrast felt
obliged to take extra pains with her own toilet.
“Now, that’s a comfort,” said Susan, “I’m in my clothes.
How bitter it is! There’s one comfort, the chapel will be
warm. I often catch forty winks in chapel—that is, if I’m
lucky enough to get behind one of the tall girls, where Mrs
Willis won’t see me. It does seem to me,” continued Susan
in a meditative tone, “the strangest thing why girls are not
allowed sleep enough.”
Hester was pinning a clean collar round her neck when Miss
Drummond came up close, leaned over the dressing-table,
and regarded her with languid curiosity.
“A penny for your thoughts. Miss Prunes and Prism.”
“Why do you call me that?” said Hester angrily.
“Because you look like it, sweet. Now, don’t be cross, little
pet—no one ever yet was cross with sleepy Susy
Drummond. Now, tell me, love, what had you for breakfast
yesterday?”
“I’m sure I forget,” said Hester.
“You forget?—how extraordinary! You’re sure that it was not
buttered scones? We have them sometimes, and I tell you
they are enough even to keep a girl awake. Well, at least
you can let me know if the eggs were very stale, and the
coffee very weak, and whether the butter was second-rate

Dorset, or good and fresh. Come now—my breakfast is of
immense importance to me, I assure you.”
“I dare say,” answered Hester. “You can see for yourself this
morning what is on the table—I can only inform you that it
was good enough for me, and that I don’t remember what it
was.”
“Oh, dear!” exclaimed Susan Drummond, “I’m afraid she
has a little temper of her own—poor little room-mate. I
wonder if chocolate-creams would sweeten that little
temper?”
“Please don’t talk—I’m going to say my prayers,” said
Hester.
She did kneel down, and made a slight effort to ask God to
help her through the day’s work and the day’s play. In
consequence, she rose from her knees with a feeling of
strength and sweetness which even the feeblest prayer
when uttered in earnest can always give.
The prayer-gong now sounded, and all the girls assembled
in the chapel. Miss Drummond was greeted by many
appreciative nods, and more than one pair of longing eyes
gazed in the direction of her pockets, which stuck out in the
most ungainly fashion.
Hester was relieved to find that her room-mate did not
share her class in school, nor sit anywhere near her at
table.
When the half-hour’s recreation after breakfast arrived,
Hester, determined to be beholden to none of her school-
mates for companionship, seated herself comfortably in an
easy chair, with a new book. Presently she was startled by a
little stream of lollipops falling in a shower over her head,

down her neck, and into her lap. She started up with an
expression of disgust. Instantly Miss Drummond sank into
the vacated chair.
“Thank you, love,” she said, in a cosy, purring voice. “Eat
your lollipops, and look at me; I’m going to sleep. Please
pull my toe when Danesbury comes in. Oh, fie! Prunes and
Prisms—not so cross—eat your lollipops; they will sweeten
the expression of that—little—face.”
The last words came out drowsily. As she said “face,” Miss
Drummond’s languid eyes were closed—she was fast asleep.

Chapter Nine.
Work And Play.
In a few days Hester was accustomed to her new life. She
fell into its routine, and in a certain measure won the
respect of her fellow-pupils. She worked hard, and kept her
place in class, and her French became a little more like the
French tongue and a little less like the English. She showed
marked ability in many of her other studies, and the
mistresses and masters spoke well of her. After a fortnight
spent at Lavender House, Hester had to acknowledge that
the little Misses Bruce were right, and that school might be
a really enjoyable place for some girls. She would not yet
admit that it could be enjoyable for her. Hester was too shy,
too proud, too exacting to be popular with her school-
fellows. She knew nothing of school-girl life—she had never
learned the great secret of success in all life’s perplexities,
the power to give and take. It never occurred to Hester to
look over a hasty word, to take no notice of an envious or
insolent look. As far as her lessons were concerned she was
doing well; but the hardest lesson of all, the training of
mind and character, which the daily companionship of her
school-fellows alone could give her, in this lesson she was
making no way. Each day she was shutting herself up more
and more from all kindly advances, and the only one in the
school whom she sincerely and cordially liked was gentle
Cecil Temple.
Mrs Willis had some ideas with regard to the training of her
young people which were peculiarly her own. She had found
them successful, and, during her thirty years’ experience,
had never seen reason to alter them. She was determined
to give her girls a great deal more liberty than was

accorded in most of the boarding-schools of her day. She
never made what she called impossible rules; she allowed
the girls full liberty to chatter in their bedrooms; she did not
watch them during play-hours; she never read the letters
they received, and only superintended the specimen home
letter which each girl was required to write once a month.
Other head-mistresses wondered at the latitude she allowed
her girls, but she invariably replied—
“I always find it works best to trust them. If a girl is found
to be utterly untrustworthy. I don’t expel her, but I request
her parents to remove her to a more strict school.”
Mrs Willis also believed much in that quiet half-hour each
evening, when the girls who cared to come could talk to her
alone. On these occasions she always dropped the school-
mistress and adopted the rôle of the mother. With a very
refractory pupil she spoke in the tenderest tones of
remonstrance and affection at these times. If her words
failed—if the discipline of the day and the gentle sympathy
of these moments at night did not effect their purpose, she
had yet another expedient—the vicar was asked to see the
girl who would not yield to this motherly influence.
Mr Everard had very seldom taken Mrs Willis’s place. As he
said to her, “Your influence must be the mainspring. At
supreme moments I will help you with personal influence,
but otherwise, except for my nightly prayers with your girls,
and my weekly class, and the teachings which they with
others hear from my lips Sunday after Sunday, they had
better look to you.”
The girls knew this rule well, and the one or two rare
instances in the school history where the vicar had stepped
in to interfere, were spoken of with bated breath and with
intense awe.

Mrs Willis had a great idea of bringing as much happiness
as possible into young lives. It was with this idea that she
had the quaint little compartments railed off in the play-
room.
“For the elder girls,” she would say, “there is no pleasure so
great as having, however small the spot, a little liberty hall
of their own. In her compartment each girl is absolute
monarch. No one can enter inside the little curtained rail
without her permission. Here she can show her individual
taste, her individual ideas. Here she can keep her most-
prized possessions. In short, her compartment in the play-
room is a little home to her.”
The play-room, large as it was, admitted of only twenty
compartments; these compartments were not easily won.
No amount of cleverness attained them; they were
altogether dependent on conduct. No girl could be the
honourable owner of her own little drawing-room until she
had distinguished herself by some special act of kindness
and self-denial. Mrs Willis had no fixed rule on this subject.
She alone gave away the compartments, and she often
made choice of girls on whom she conferred this honour in
a way which rather puzzled and surprised their fellows.
When the compartment was won it was not a secure
possession. To retain it depended also on conduct; and here
again Mrs Willis was absolute in her sway. More than once
the girls had entered the room in the morning to find some
favourite’s furniture removed and her little possessions
taken carefully down from the walls, the girl herself alone
knowing the reason for this sudden change. Annie Forest,
who had been at Lavender House for four years, had once,
for a solitary month of her existence, owned her own special
drawing-room. She had obtained it as a reward for an act of
heroism. One of the little pupils had set her pinafore on fire.

There was no teacher present at the moment—the other
girls had screamed and run for help, but Annie, very pale,
had caught the little one in her arms and had crushed out
the flames with her own hands. The child’s life was spared,
the child was not even hurt, but Annie was in the hospital
for a week. At the end of a week she returned to the
school-room and play-room as the heroine of the hour. Mrs
Willis herself kissed her brow, and presented her in the
midst of the approving smiles of her companions with the
prettiest drawing-room of the sets. Annie retained her
honourable post for one month.
Never did the girls of Lavender House forget the delights of
that month. The fantastic arrangements of the little
drawing-room filled them with ecstasies. Annie was truly
Japanese in her style—she was also intensely liberal in all
her arrangements. In the tiny space of this little inclosure
wild pranks were perpetrated, ceaseless jokes made up.
From Annie’s drawing-room issued peals of exquisite mirth.
She gave afternoon tea from a Japanese set of tea-things.
Outside her drawing-room always collected a crowd of girls,
who tried to peep over the rail or to draw aside the curtains.
Inside the sacred spot certainly reigned chaos, and one day
Miss Danesbury had to fly to the rescue, for in a fit of mad
mirth Annie herself had knocked down the little Japanese
tea-table, the tea-pot and tea-things were in fragments on
the floor, and the tea and milk poured in streams outside
the curtains. Mrs Willis sent for Annie that evening, and
Miss Forest retired from her interview with red eyes and a
meek expression.
“Girls,” she said, in confidence that night, “good-bye to
Japan. I gave her leave to do it—the care of an empire is
more than I can manage.”

The next day the Japanese drawing-room had been handed
over to another possessor, and Annie reigned as queen over
her empire no more.
Mrs Willis, anxious at all times that her girls should be
happy, made special arrangements for their benefit on
Sunday. Sunday was by no means dull at Lavender House—
Sunday was totally unlike the six days which followed it.
Even the stupidest girl could scarcely complain of the
severity of Sunday lessons—even the merriest girl could
scarcely speak of the day as dull. Mrs Willis made an
invariable rule of spending all Sunday with her pupils. On
this day she really unbent—on this day she was all during
the long hours, what she was during the short half-hour on
each evening in the week. On Sunday she neither reproved
nor corrected. If punishment or correction were necessary,
she deputed Miss Good or Miss Danesbury to take her place.
On Sunday she sat with the little children round her knee,
and the older girls clustering about her. Her gracious and
motherly face was like a sun shining in the midst of these
young girls. In short, she was like the personified form of
Goodness in their midst. It was necessary, therefore, that
all those who wished to do right should be happy on
Sunday, and only those few who deliberately preferred evil
should shrink from the brightness of this day.
It is astonishing how much a sympathising and guiding
spirit can effect. The girls at Lavender House thought
Sunday the shortest day in the week. There were no
unoccupied or dull moments—school toil was forgotten—
school punishment ceased, to be resumed again if
necessary on Monday morning. The girls in their best
dresses could chatter freely in English—they could read
their favourite books—they could wander about the house
as they pleased: for on Sunday the two baize doors were
always wide-open, and Mrs Willis’s own private suite of

rooms was ready to receive them. If the day was fine they
walked to church, each choosing her own companion for the
pleasant walk; if the day was wet there was service in the
chapel, Mr Everard always conducting either morning or
evening prayers. In the afternoon the girls were allowed to
do pretty much as they pleased, but after tea there always
came a delightful hour, when the elder girls retired with
their mistress into her own special boudoir, and she either
told them stories or sang to them as only she could sing. At
sixty years of age Mrs Willis still possessed the most
sympathetic and touching voice those girls had ever listened
to. Hester Thornton broke down completely on her first
Sunday at Lavender House when she heard her school-
mistress sing “The Better Land.” No one remarked on her
tears, but two people saw them; for her mistress kissed her
tenderly that night, and said a few strong words of help and
encouragement, and Annie Forest, who made no comment,
had also seen them, and wondered vaguely if this new and
disagreeable pupil had a heart after all.
On Sunday night Mrs Willis herself went round to each little
bed and gave a mother-kiss to each of her pupils—a
mother-kiss and a murmured blessing; and in many breasts
resolves were then formed which were to help the girls
through the coming week. Some of these resolves, made
not in their own strength, bore fruit in long after-years.
There is no doubt that very few girls who lived long enough
at Lavender House ever in after-days found their Sundays
dull.

Chapter Ten.
Varieties.
Without any doubt, wild, naughty, impulsive Annie Forest
was the most popular girl in the school. She was always in
scrapes—she was scarcely ever out of hot water—her
promises of amendment were truly like the proverbial pie-
crust: but she was so lovable, so kind-hearted, so saucy
and piquant and pretty, that very few could resist the
nameless charm which she possessed. The little ones
adored Annie, who was kindness itself to them; the bigger
girls could not help admiring her fearlessness and courage;
the best and noblest girls in the school tried to influence her
for good. She was more or less an object of interest to
every one; her courage was of just the sort to captivate
school-girls, and her moral weakness was not observed by
these inexperienced young eyes.
Hester alone, of all the girls who for a long time had come
to Lavender House, failed to see any charm in Annie. She
began by considering her ill-bred, and when she found she
was the school favourite, she tossed her proud little head
and determined that she for one would never be subjugated
by such a naughty girl. Hester could read character with
tolerable clearness; she was an observant child—very
observant, and very thoughtful for her twelve years; and as
the little witch Annie had failed to throw any spell over her,
she saw her faults far more clearly than did her
companions. There is no doubt that this brilliant, charming,
and naughty Annie had heaps of faults; she had no
perseverance; she was all passion and impulse; she could
be the kindest of the kind, but from sheer thoughtlessness
and wildness she often inflicted severe pain, even on those

she loved best. Annie very nearly worshipped Mrs Willis, she
had the most intense adoration for her, she respected her
beyond any other human being. There were moments when
the impulsive and hot-headed child felt that she could gladly
lay down her life for her school-mistress. Once the mistress
was ill, and Annie curled herself up all night outside her
door, thereby breaking rules, and giving herself a severe
cold; but her passion and agony were so great that she
could only be soothed by at last stealing into the darkened
room and kissing the face she loved.
“Prove your love to me, Annie, by going downstairs and
keeping the school rules as perfectly as possible,” whispered
the teacher.
“I will—I will never break a rule again as long as I live, if
you get better, Mrs Willis,” responded the child.
She ran downstairs with her resolves strong within her, and
yet in half an hour she was reprimanded for wilful and
desperate disobedience.
One day Cecil Temple had invited a select number of friends
to afternoon tea in her little drawing-room. It was the
Wednesday half-holiday, and Cecil’s tea, poured into the
tiniest cups and accompanied by thin wafer biscuits, was of
the most recherché quality. Cecil had invited Hester
Thornton, and a tall girl who belonged to the first-class and
whose name was Dora Russell, to partake of this dainty
beverage. They were sitting round the tiny tea-table, on
little red stools with groups of flowers artistically painted on
them, and were all three conducting themselves in a most
ladylike and refined manner, when Annie Forest’s curly head
and saucy face popped over the inclosure, and her voice
said eagerly—

“Oh, may I be permitted to enter the shrine?”
“Certainly, Annie,” said Cecil, in her most cordial tones. “I
have got another cup and saucer, and there is a little tea
left in the tea-pot.”
Annie came in, and ensconced herself cosily on the floor. It
did not matter in the least to her that Hester Thornton’s
brow grew dark, and that Miss Russell suddenly froze into
complete indifference to all her surroundings. Annie was full
of a subject which excited her very much; she had suddenly
discovered that she wanted to give Mrs Willis a present, and
she wished to know if any of the girls would like to join her.
“I will give her the present this day week,” said excitable
Annie. “I have quite made up my mind. Will any one join
me?”
“But there is nothing special about this day week, Annie,”
said Miss Temple. “It will neither be Mrs Willis’s birthday,
nor Christmas Day, nor New Year’s Day, nor Easter Day.
Next Wednesday will be just like any other Wednesday. Why
should we make Mrs Willis a present?”
“Oh, because she looks as if she wanted one, poor dear. I
thought she looked sad this morning; her eyes drooped and
her mouth was down at the corners. I am sure she’s
wanting something from us all by now, just to show that we
love her, you know.”
“Pshaw!” here burst from Hester’s lips.
“Why do you say that?” said Annie, turning round with her
bright eyes flashing. “You’ve no right to be so contemptuous
when I speak about our—our head-mistress. Oh, Cecil,” she
continued, “do let us give her a little surprise—some spring
flowers, or something just to show her that we love her.”

“But you don’t love her,” said Hester, stoutly.
Here was throwing down the gauntlet with a vengeance!
Annie sprang to her feet and confronted Hester with a whole
torrent of angry words. Hester firmly maintained her
position. She said over and over again that love proved
itself by deeds, not by words; that if Annie learned her
lessons, and obeyed the school rules, she would prove her
affection for Mrs Willis far more than by empty
protestations. Hester’s words were true, but they were
uttered in an unkind spirit, and the very flavour of truth
which they possessed caused them to enter Annie’s heart
and to wound her deeply. She turned, not red, but very
white, and her large and lovely eyes grew misty with
unshed tears.
“You are cruel,” she gasped, rather than spoke, and then
she pushed aside the curtains of Cecil’s compartment and
walked out of the play-room.
There was a dead silence among the three girls when she
left them. Hester’s heart was still hot, and she was still
inclined to maintain her own position, and to believe she
had done right in speaking in so severe a tone to Annie. But
even she had been made a little uneasy by the look of deep
suffering which had suddenly transformed Annie’s charming
childish face into that of a troubled and pained woman. She
sat down meekly on her little three-legged stool and, taking
up her tiny cup and saucer, sipped some of the cold tea.
Cecil Temple was the first to speak.
“How could you?” she said, in an indignant voice for her.
“Annie is not the girl to be driven, and, in any case, it is not
for you to correct her. Oh, Mrs Willis would have been so
pained had she heard you—you were not kind, Miss

Thornton. There, I don’t wish to be rude, but I fear I must
leave you and Miss Russell—I must try and find Annie.”
“I’m going back to my own drawing-room,” said Miss
Russell, rising to her feet. “Perhaps,” she added, turning
round with a very gracious smile to Hester, “you will come
and see me there, after tea, this evening.”
Miss Russell drew aside the curtains of Cecil Temple’s little
room, and disappeared. Hester, with her eyes full of tears,
now turned eagerly to Cecil.
“Forgive me, Cecil,” she exclaimed. “I did not mean to be
unkind, but it is really quite ridiculous the way you all spoil
that girl—you know as well as I do that she is a very
naughty girl. I suppose it is because of her pretty face,”
continued Hester, “that you are all so unjust, and so blind to
her faults.”
“You are prejudiced the other way, Hester,” said Cecil in a
more gentle tone. “You have disliked Annie from the first.
There, don’t keep me—I must go to her now. There is no
knowing what harm your words may have done. Annie is
not like other girls. If you knew her story, you would
perhaps be kinder to her.”
Cecil then ran out of her drawing-room, leaving Hester in
sole possession of the little tea-things and the three-legged
stools. She sat and thought for some time; she was a girl
with a great deal of obstinacy in her nature, and she was
not disposed to yield her own point, even to Cecil Temple;
but Cecil’s words had, nevertheless, made some impression
on her.
At tea-time that night, Annie and Cecil entered the room
together. Annie’s eyes were as bright as stars, and her
usually pale cheeks glowed with a deep colour. She had

Welcome to our website – the perfect destination for book lovers and
knowledge seekers. We believe that every book holds a new world,
offering opportunities for learning, discovery, and personal growth.
That’s why we are dedicated to bringing you a diverse collection of
books, ranging from classic literature and specialized publications to
self-development guides and children's books.
More than just a book-buying platform, we strive to be a bridge
connecting you with timeless cultural and intellectual values. With an
elegant, user-friendly interface and a smart search system, you can
quickly find the books that best suit your interests. Additionally,
our special promotions and home delivery services help you save time
and fully enjoy the joy of reading.
Join us on a journey of knowledge exploration, passion nurturing, and
personal growth every day!
ebookbell.com

Multiagent Systems Mdlg Ctl Pgmg Simuls Applns F Alkhateeb

More Related Content

Similar to Multiagent Systems Mdlg Ctl Pgmg Simuls Applns F Alkhateeb (20)

Recently uploaded (20)

Multiagent Systems Mdlg Ctl Pgmg Simuls Applns F Alkhateeb