A Modularized and Reusable Architecture for an Embedded MAS IDE

Gabriel Ramos Alves Lima

1 a

, Elaine Maria Pereira Siqueira

1 b

, Th

acito R. Costa Medeiros

1 c

Carlos Eduardo Pantoja

1 d

, Nilson Mori Lazarin

1,2 e

and Jos

e Viterbo

2 f

Federal Center for Technological Education Celso Suckow da Fonseca (Cefet/RJ), Rio de Janeiro, Brazil

Institute of Computing, Fluminense Federal University (UFF), Niter

oi - RJ, Brazil

{gabriel.ramos, elaine.siqueira, thacito.medeiros}@aluno.cefet-rj.br,

Keywords:

Multi-Agent Systems, Software Architecture, Software Engineering, IDE, ChonIDE.

Abstract:

The rise of the Embedded Multi-Agent Systems (MAS) ﬁeld brings challenges regarding technologies speciﬁ-

cally tailored for development in this area. Among these, chonIDE, as a new Integrated Development Environ-

ment (IDE) dedicated to this newly explored scenario, has gaps in its code that can be improved to meet market

demands. In this regard, this paper outlines a new architecture through the restructuring of the components

of this IDE to make it more scalable and, consequently, mitigate challenges in the Embedded MAS scenario.

Additionally, changes in ﬁle structure are suggested to promote code versioning and enhance interoperability

with other IDEs at the project reuse level, thus making it better adapted to market demands.

1 INTRODUCTION

Changes in the characteristics and expectations of

software systems have led to the emergence of a se-

ries of new software engineering challenges (Ten-

nenhouse, 2000; Zambonelli and Van Dyke Parunak,

2003). In this new scenario, the use of Multi-Agent

Systems (MAS) is advocated as a software engineer-

ing paradigm for designing and developing software

systems (Wooldridge and Jennings, 1995; Jennings,

2001; Wooldridge, 2009). In MAS, applications are

designed and developed in terms of autonomous soft-

ware entities (agents) that can achieve their goals

with ﬂexibility by interacting with each other through

high-level protocols and languages. These character-

istics are well-suited for addressing emerging com-

plexities (Zambonelli et al., 2003).

Integrated Development Environments (IDEs)

widespread in the market, although sufﬁciently meet-

ing the user experience aspect by offering features

such as code versioning, indentation, syntax high-

lighting, among others, do not address the decen-

tralized nature of distributed systems with agents

https://orcid.org/0009-0009-3233-9408

https://orcid.org/0009-0006-1879-4891

https://orcid.org/0009-0009-3310-714X

https://orcid.org/0000-0002-7099-4974

https://orcid.org/0000-0002-4240-3997

https://orcid.org/0000-0002-0339-6624

(Tennenhouse, 2000). This is because these sys-

tems have unique contextual needs, such as remote

embedding of projects, Agent-Oriented Programming

(AOP), and embedding of devices on single-board

computers, monitoring agent interactions and percep-

tions, among others.

The success and general implementation of com-

plex software systems based on Multi-Agent Systems

(MAS) require new models and technologies (Zam-

bonelli et al., 2003). Among these technologies,

chonIDE (Souza de Jesus et al., 2023) stands out in

supporting Embedded MAS compared to other IDEs

due to its specialized nature, which takes into account

the speciﬁc demands of this scenario. However, the

architecture of chonIDE is not ﬂexible or extensible

to changes, due to its tightly coupled nature, which

leads to low scalability potential regarding features. It

also does not ensure interoperability, as the ﬁle struc-

ture of its projects is not compatible with other IDEs,

preventing the reuse of its projects.

Therefore, this paper proposes a new architecture

for chonIDE through the restructuring of its compo-

nents, aiming to make it less tightly coupled and, con-

sequently, more scalable to enable the addition of new

functionalities via third parties and facilitate unit test-

ing, extensibility, and ﬂexibility, among others. Ad-

ditionally, a new folder and ﬁle structure has been

implemented to provide code versioning and ensure

interoperability between projects.

1034

Lima, G. R. A., Siqueira, E. M. P., Medeiros, T. R. C., Pantoja, C. E., Lazarin, N. M. and Viterbo, J.

A Modularized and Reusable Architecture for an Embedded MAS IDE.

DOI: 10.5220/0013439600003929

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 27th International Conference on Enterprise Information Systems (ICEIS 2025) - Volume 1, pages 1034-1045

ISBN: 978-989-758-749-8; ISSN: 2184-4992

This paper is organized as follows: Section 2

presents an extended comparative table of related

work; Section 3 explains the components of the

toolkit, their respective functions, and relationships;

Section 4 introduces the new modular and scalable

architecture, including the modeling and implemen-

tation that enable the folder and ﬁle structure for

projects; and ﬁnally, Section 5 discusses the ﬁnal con-

siderations and expectations for future work.

2 RELATED WORK

A comparative analysis of IDEs for Embedded MAS

Development (Siqueira et al., 2024) considered vari-

ous software development factors by comparing pop-

ular IDEs on the market with the availability of

IDEs for Embedded MAS development. In this case,

the comparison took into account Eclipse, VSCode,

and IntelliJ IDEs based on the following characteris-

tics: installation, platforms, usage license, user man-

ual, user community, developer community, interface,

compilers or interpreters, debugger, editor, syntax

checking, syntax highlighting, autocompletion, quick

help, and indenting.

Considering the context of Embedded MAS, it is

relevant to add functionalities such as remote project

deployment, Agent-Oriented Programming, deploy-

ment on single-board computers, and monitoring of

agent interactions and perceptions to the analysis cri-

teria of the table. These characteristics increase the

level of abstraction between the developer and the re-

sources used in software engineering processes, al-

lowing them to focus primarily on designing the ap-

plication they are creating without worrying about, for

example, manual integration conﬁgurations that are

necessary when using general-purpose tools.

Furthermore, the installation of the IDE should

be easy and quick, allowing the user to start using it

as soon as possible. It is important for the IDE to

work on the most common hardware/software plat-

forms, including Windows, Linux, and macOS. IDEs

distributed under open-source licenses are preferable

due to their accessibility. It is desirable that the user

manual be as complete as possible so that the user can

resolve initial doubts without having to search in fo-

rums. A large community is a positive aspect, as it

facilitates the resolution of any issues that may arise.

Typically, IDEs developed by groups receive updates

more quickly than those developed by a single per-

son. The interface should be intuitive, clean, and user-

friendly (Siqueira et al., 2024). Table 1 shows the

comparison of desired functionalities in an IDE.

It is highly desirable for the debugger to be in-

tegrated, as it facilitates the identiﬁcation of logical

issues. A powerful editor with various features can be

helpful, such as line numbering for locating reported

errors, multiple tabs for quick viewing of different

ﬁles, and current line highlighting for easier naviga-

tion within the ﬁle, among other features considered

below. Syntax checking is a very useful feature, as

it notiﬁes the user when there is something wrong

with the code before the compiler or interpreter is run.

Syntax highlighting is important, as it displays the

code in a way that makes it easy to visualize and lo-

cate functions, variables, constants, strings, operators,

and more. Autocompletion aids in typing the code,

reducing errors. Quick help provides tips when the

mouse hovers over certain parts of the code. The in-

denting feature is responsible for formatting the code,

helping with its organization, and improving readabil-

ity.

Table 1: Functionalities Comparison between IDEs.

chonIDE Eclipse VSCode IntelliJ

Easy to Install

Multiplatform

Multilingual

Free to Use

Clean Interface

Debugger

Syntax Check

Syntax Highlighting

Autocomplete

Quick Help

Multiple Tabs

User Manual

File Viewer

Line Counter

Highlighted

Current Line

Indentation

Remote Deployment

of Projects

Single Interface to

Embedded MAS Pro-

gramming Paradigms

Monitoring agents

interactions

and perceptions

3 FRAMEWORK

The chonIDE (Jesus et al., 2022; Souza de Jesus

et al., 2023) is an environment that integrates, within

a single-screen experience, both a set of technolo-

gies enabling the development of Embedded MAS

and typical features of a modern IDE that assist dur-

ing software design and allows designers to access

and use these development resources effectively. This

section explores the software components of chonIDE

and their relationships with other parts of the toolkit

for developing Embedded MAS, presented in Figure

1, to describe the IDE’s functionality.

A Modularized and Reusable Architecture for an Embedded MAS IDE

1035

Figure 1: ChonIDE System Flow.

The interfacing between chonIDE (1), the imple-

mentation, and the management of the system de-

signed by the developer is performed by chonOS:

Cognitive Hardware on Network - Operating Sys-

tem

(2), a GNU/Linux distribution with the speciﬁc

purpose of facilitating the conception and use of Em-

bedded MAS This solution introduces a new layer

into the development architecture (Lazarin et al.,

2023). Alongside the four existing layers— Hard-

ware, Firmware, Interface, and Reasoning (Pantoja

et al., 2016) — a ﬁfth layer, Management, is added.

This layer enables remote control between the de-

veloper’s computer and single-board embedded hard-

ware (e.g., Raspberry Pi), achieved through Shell

Script-based services and modules (2.1 and 2.2) that

abstract different technological dependencies, provid-

ing access to several real-time resources. This capa-

bility spans the entire embedding experience through

SSH communication within the same Wi-Fi network

(2, 6, and 7).

Thus, remote management of the Firmware and

Reasoning layers of the embedded hardware by the

designer is made possible, with emphasis on:

• Sending source code to the Arduino boards (5) us-

ing the Arduino CLI (4).

• Implementing the Embedded MAS through the

BDI frameworks supported by the distribution —

Jason (Bordini et al., 2007), JaCaMo (Boissier

et al., 2020), and Jason Embedded (Pantoja et al.,

2023) (3).

• Visualization of agent logs — event and mes-

sage records — during Embedded SMA activity

and other system information through log service

(2.2), a web page incorporated directly into the

https://os.chon.group

graphical interface (1.2).

Among the BDI frameworks previously men-

tioned for the implementation of MAS, the IDE uses,

via ChonOS (2), the Jason Embedded (3), which is an

extended version of Jason (Bordini et al., 2005) that

supports the development of Embedded MAS to pro-

vide autonomy and communicability to IoT devices

and mobility and adaptability to agents (Pantoja et al.,

2023). Additionally, this component includes a fea-

ture called the Mind API (3.1), a REST API that al-

lows inspection of the agents’ minds—beliefs, rules,

intentions, and plans—at a given cycle. Through the

application (1.1), it is possible to query the most re-

cent state of all agents or a speciﬁc agent within a

particular cycle directly via the Mind Inspector graph-

ical component, integrated into the right sidebar of the

chonIDE interface (1.2).

Finally, the application (1.1) should serve as the

integration and provision platform for the functionali-

ties of the components that enable the development of

Embedded MAS (2 and 3), as well as resources char-

acteristic of an enhanced programming experience —

such as the system management dynamics of the IDE

project ﬁles, which will be structured, and the source

code versioning through Git, which will be enabled

— all in a uniform and centralized manner, speciﬁed

through an API for consumption by the user inter-

face (1.2), which is also provided by this component

for the developer’s Browser (8) (e.g., Mozilla Firefox,

Google Chrome).

That being said, after specifying the parts that

make up the IDE system, its resources, and their re-

spective relationships, it is necessary to deﬁne a re-

structuring and establish an architecture for the appli-

cation (1.1) that is capable of integrating the differ-

ent mechanics and resources of the toolset in a scal-

able, modular, and decoupled manner. This new ar-

ICEIS 2025 - 27th International Conference on Enterprise Information Systems

1036

chitecture should facilitate implementing and scaling

new functionalities, such as project ﬁle management

within the IDE and versioning through Git.

4 THE ARCHITECTURE

The IDE application consists of a web layer, which

provides the pages for the developer’s browser and

speciﬁes an API responsible for managing commu-

nication with the user interface, and an implementa-

tion layer, which is responsible for implementing the

integration, access methods, and manipulation of the

development resources provided by the solution.

In this context, the implementation layer conse-

quently centralizes elements that handle data persis-

tence, communication with external services, util-

ity mechanics, domain dynamics, and business logic,

which makes the structure tightly coupled. As a re-

sult, it is not feasible to ensure aspects such as scala-

bility, the extensibility of current and future function-

alities, and the creation of unit tests — key aspects for

solutions that encompass a variety of dynamics within

the same context.

Based on the presented scenario, an architec-

ture modularizing the implementation layer should

be deﬁned. Considering that the source code is im-

plemented in Java, object-oriented concepts such as

inheritance, composition, interfaces, polymorphism,

and dependency injections (Fowler, 2004) are ex-

plored. Additionally, structures based on design pat-

terns (Gamma, 1995) and layer patterns (Fowler,

2002) are employed.

4.1 Layers

It is proposed to divide the implementation layer into

three other layers for the architectural process: in-

frastructure, application, and domain (Fowler, 2002;

Evans, 2004). This approach organizes the structure

into hierarchical levels to separate responsibilities and

simplify system maintenance and evolution. Further-

more, abstractions will be deﬁned to promote mod-

ularization and low coupling as they establish clear

responsibilities for the application’s elements.

Initially, it is necessary to understand the nature of

access to the development resources to deﬁne the el-

ements responsible for interfacing with these external

means in a decoupled manner.

Based on the dynamics shown in Figure 2, it is

possible to determine the interfaces and implementa-

tions that deﬁne the access methods to the develop-

ment resources. For persistence in the ﬁle system:

Figure 2: Access methods to development resources.

• FileRepository: Interface that deﬁnes ﬁle manipu-

lation operations such as reading, creating, updat-

ing , and deleting (Figure 3).

– LocalFileRepository: Implements ﬁle manipu-

lation on the machine system on which the ap-

plication operates (locally) using native Java li-

braries.

For executing commands via the prompt, also

considering aspects such as remote access via

SSH, the following are deﬁned:

• CommandPromptRunner: Interface that deﬁnes

the execution of commands via terminal (Fig-

ure 4).

– LocalCommandPromptRunner: Implements

the execution of commands on the machine’s

local terminal on which the application oper-

ates (local).

• SSHHandler: Interface that deﬁnes access to SSH

resources (e.g., SFTP) and the remote execution

of commands via terminal (extends Command-

PromptRunner) (Figure 4).

– JschSshHandler: The default implementation

of this abstraction, using the JSCH library

For access to Web APIs, the following is deﬁned:

• HttpClient: Interface that deﬁnes communica-

tion operations via the HTTP protocol, con-

sidering aspects such as request (HttpRequest)

and response (HttpResponse): data body (Http-

Body); request parameters (HttpQueryParame-

ter); request method (HttpMethod); and the re-

sponse return code (Figure 5).

– StandardHttpClient: The default implementa-

tion of this abstraction, using native Java li-

braries.

The interfaces presented follow the ports pattern

(Fowler, 2002) — CommandPromptRunner and Http-

Client — and the repositories pattern (Evans, 2004)

Available at http://www.jcraft.com/jsch/

A Modularized and Reusable Architecture for an Embedded MAS IDE

1037

Figure 3: File persistence interface and classes.

Figure 4: SSH and Prompt Executor interface and classes.

Figure 5: HTTP client interface and classes.

— FileRepository. Both abstract technical details and

encapsulate the communication that enables access

and manipulation of an external resource, providing

a single entry point for requests and abstracting the

complexity of an underlying system. At the same

time, the implementations serve as adapters (Fowler,

2002) , determining real behavior within the system

inﬂuenced by a speciﬁc technology or the desired

context.

Additionally, a reusable instance is required to

convert json into object instances (and vice versa),

enabling the manipulation of response contents from

the Mind API, chonOS modules, and, eventually, Git

when applicable. For this purpose, is deﬁned a strat-

egy (Gamma, 1995) that provides access to this im-

plementation, and a singleton (Gamma, 1995) that en-

sures a unique instance for the system:

• JsonConverter: Interface that deﬁnes the opera-

tions for serializing and deserializing JSON con-

tent to instances of application classes (Figure 6).

Figure 6: Json classes.

– StandardJsonConverter: The default imple-

mentation of this abstraction, using native Java

libraries (Corporation, 2024).

• JsonConverterProvider: Singleton that provides a

unique instance of JsonConverter for the applica-

tion (Figure 6).

Considering that the implementations deﬁned —

adapters and strategies — are purely technical and

disconnected from any business logic, they should be

directed to the infrastructure layer, which is respon-

sible for providing the necessary technical and utility

services for the other layers of the architecture (appli-

cation and domain), such as communication with ex-

ternal services, data persistence, and utility elements.

Thus, it is possible to decouple the technical imple-

mentation for external access from the rest of the ap-

plication.

Moreover, an application layer is established,

which, through application services, is responsible

for orchestrating use cases and coordinating activi-

ties between elements that provide access to the de-

velopment resources. Thus, by merely determining

these two layers (infrastructure and application) and

their elements, it is possible to provide access to the

Mind API, chonOS, and, in the future, Git, as exter-

nal services deﬁne their operating mechanics, in other

words, they are not part of the IDE application do-

main, so do not require extensive manipulation of re-

turned content or internal logic.

However, in the case of managing project ﬁle sys-

tems, business rules need to be added since its me-

chanics will be deﬁned by the application, given that

it is a development resource within the IDE domain.

For this case, a domain layer is deﬁned, with its

respective domain services, which encapsulate a set

of operations containing system logic for managing

multiple entities or data sources, and domain models

(Evans, 2004), which are abstractions designed to re-

ﬂect business concepts and behaviors and serve as a

cohesive core for organizing and expressing system

knowledge.

In this way, a decoupled architecture between its

elements and modularized layers is achieved, allow-

ing the system’s scalability, as demonstrated in Figure

7. From this general deﬁnition, the next subsections

ICEIS 2025 - 27th International Conference on Enterprise Information Systems

1038

Figure 7: Application architecture.

will detail the speciﬁc abstractions and their use cases

for accessing the development resources.

4.2 chonOS

The chonOS distribution provides functionalities that

streamline the deployment and management process

of Embedded MAS by introducing a set of modules

accessed via Shell Script, which are as follows:

• chonosEmbeddedMAS

promotes the manage-

ment of BDI-based Embedded MAS at the rea-

soning layer of the system through the use of in-

terpreters supported by the solution— Jason (Bor-

dini et al., 2007), JaCaMo (Boissier et al., 2020),

or Jason Embedded (Pantoja et al., 2023), al-

lowing the project to be deployed, started, and

stopped.

• chonosFirmwareManager

enables communica-

tion with the interface and ﬁrmware layers, thus

facilitating the deployment and updating of source

https://os.chon.group/masmng/

https://os.chon.group/ﬁrmwaremng/

code for Arduino boards, the detailed display of

information about boards connected to the hard-

ware, and the import, removal, and listing of li-

braries.

• chonosDDNSManager

allows the deﬁnition and

updating of the Fully Qualiﬁed Domain Name

(FQDN) for the device, thereby eliminating the

need for the designer to know the embedded hard-

ware’s IP address on the current network.

• chonosWiﬁConn and chonosWiﬁConf

enable the

management of embedded hardware connectiv-

ity. They allow connection to a network in client

mode, the creation of a private network in AP

mode (with or without encryption), and the de-

tailed display of the connected network as well as

other nearby networks.

• chonosNeighbors

allows the identiﬁcation of all

embedded hardware devices on current network.

https://os.chon.group/ddnsmng/

https://os.chon.group/networkmng/

https://os.chon.group/neighborsmng/

A Modularized and Reusable Architecture for an Embedded MAS IDE

1039

Figure 8: ChonOS services.

Based on this, each of the mentioned modules

is considered a development resource and must have

corresponding access abstractions. This will be

reﬂected in services within the application layer

that receive dependency injections from Command-

PromptRunner and JsonConverter. These services al-

low module execution via command prompt — ei-

ther locally (LocalCommandPromptRunner) on the

designer’s computer or remotely (JschSshHandler)

on the embedded hardware — and serialize the re-

sponse into object instances for straightforward ma-

nipulations, as illustrated in Figure 8.

4.3 Mind API

The Mind API is a REST API that provides infor-

mation about the current state or a speciﬁc cycle of

the agents’ minds in the MAS executed by the Jason

Embedded interpreter. To enable its access as a de-

velopment resource, a deﬁned service within the ap-

plication layer receives dependency injections from

HttpClient to consume the API’s endpoints and Json-

Converter for response deserialization, as illustrated

in Figure 9.

Figure 9: Mind API Service.

4.4 IDE Project File System

The modeling was designed to support the use of the

Jason Embedded language and enable the extensi-

bility needed for integration with the JaCaMo plat-

form, providing a solid foundation for projects that

require modularity, scalability, and alignment with

agent-oriented programming paradigms.

The new structure emerged from the need to re-

organize folders and ﬁles in the IDE to improve

project control and management. In the previous

chonIDE, the entire project was stored in a sin-

gle .json ﬁle, hindering modularity and the integra-

tion of new functionalities. The proposed struc-

ture was developed to focus on future compatibility

with the JaCaMo platform, an open-source technol-

ogy for MAS that organizes projects across three di-

mensions: agents, environments, and organization.

These dimensions are implemented using Jason, for

programming autonomous agents; CArtAgO, which

models and manages artifacts in the environment;

and MOISE, which speciﬁes and regulates multi-

agent organizations (Boissier et al., 2020). Figure

10 illustrates the planned folder structure, includ-

ing directories such as agent, environment (subdi-

vided into endogenous and exogenous), and organi-

zation, alongside example ﬁles such as agent.asl, ar-

tifact.java, ﬁle.ino, lib.zip, and project conﬁguration

ﬁles (project.jcm or project.mas2j).

The folder structure modeling within the IDE do-

main organizes Embedded MAS projects across the

three dimensions and includes a project conﬁguration

ﬁle. Figure 11 illustrates this architecture, highlight-

ing the relationship between the Project and Embed-

dedMAS classes, representing a project in IDE and

an Embedded Multi-Agent System, respectively. The

EmbeddedMAS class directly connects the three main

dimensions, represented by the Agency, Environment,

and Organization classes, to the project conﬁgura-

tion ﬁle. The MasConﬁguration interface abstracts

various conﬁguration ﬁle formats, ensuring ﬂexibil-

ity to support both Jason Embedded and JaCaMo in

the future. Additionally, the ProjectFile interface pro-

Figure 10: Proposed new folder structure.

ICEIS 2025 - 27th International Conference on Enterprise Information Systems

1040

Figure 11: Class diagram of the project’s main structure.

vides the necessary abstraction for managing the di-

verse ﬁles comprising a project. The project’s concept

classes are:

• Project. Represents a project in IDE, organizing

projects by providing a name to identify them and

linking them to an EmbeddedMAS.

• EmbeddedMAS. Represents an Embedded

MAS, connecting the dimensions of agents,

environments, and organizations, along with the

project conﬁguration ﬁle. This class centralizes

the logical structure of an Embedded MAS,

allowing the dimensions to interact cohesively

and adapt to the system’s speciﬁcities.

• ProjectFile. An interface that abstracts the differ-

ent types of ﬁles making up the project. This ab-

straction simpliﬁes the integration of various ﬁles,

such as agents, artifacts, ﬁrmware, and project

conﬁguration ﬁles, ensuring ﬂexibility and mod-

ularity in IDE’s structure.

The dimensions of agents, environment, and or-

ganization, as well as conﬁguration ﬁles, were struc-

tured independently to reﬂect the characteristics of an

Embedded MAS. This approach allows each dimen-

sion to be represented by speciﬁc classes that capture

their responsibilities and interactions, while the con-

ﬁguration layer centralizes the information necessary

for system initialization and operation. Subsequent

paragraphs will detail each of these parts, accompa-

nied by diagrams illustrating their relationships.

The agent dimension organizes agents modularly,

allowing each to be treated as an independent unit

within the project. This structure enables the integra-

tion of different types of agents into the system, re-

ﬂecting the speciﬁc demands of an Embedded MAS.

Figure 12 presents the class diagram for this dimen-

sion, highlighting agents and their respective classiﬁ-

cations.

Figure 12: Agent dimension.

The agent dimension is represented by:

• Agency. Represents the layer responsible for

grouping the agents of an Embedded MAS. It cen-

tralizes agent management and allows new agents

to be easily added to the system.

• Agent. Deﬁnes an individual agent within the

project and is modeled as an extension of the Pro-

jectFile interface, representing .asl ﬁles in the sys-

tem’s folder structure. This approach ensures each

agent is stored independently, simplifying the or-

ganization and management of agents directly at

the ﬁle level. Furthermore, the class encapsu-

lates basic agent information, such as identity and

source code, and establishes the relationship be-

tween the agent and its architecture, enabling the

coexistence of different agent types within the

same system.

• AgentArchClass. An enumeration that cate-

gorizes possible agent architectures. This enu-

meration includes Jason representing standard

agents based on the BDI (Belief-Desire-Intention)

paradigm, widely used in MAS; Argo denoting

agents with speciﬁc capabilities for interacting

with hardware or physical components, such as

sensors and actuators (Pantoja et al., 2016); and

Communicator representing agents specialized in

communication between different MAS, ensur-

ing interoperability and efﬁcient information ex-

change (Pantoja et al., 2018).

The environment dimension organizes the ele-

ments constituting the physical and logical context

in which the agents of an Embedded MAS operate.

This organization reﬂects the need for modular sepa-

ration between external aspects, related to the physi-

cal world, and internal ones, which are computational

abstractions used by agents to logically and efﬁciently

A Modularized and Reusable Architecture for an Embedded MAS IDE

1041

Figure 13: Environment dimension.

interact with the environment. Figure 13 presents the

class diagram for this dimension, illustrating how the

Environment class organizes the two types of envi-

ronments — exogenous (ExogenousEnv) and endoge-

nous (EndogenousEnv) — along with their respective

components.

The agent environment is represented by:

• Environment. The main class representing the

environment dimension in the project. It encapsu-

lates references to the exogenous and endogenous

environments, centralizing their management and

allowing integrated manipulation.

• ExogenousEnv. Represents the exogenous en-

vironment, which includes external elements such

as physical devices and libraries required for op-

eration (Ricci et al., 2012). This implementation

contains references to the Firmware and Library

classes, which represent ﬁles in this environment.

• Firmware. Project ﬁles (.ino) that encapsulate

the logic for controlling physical devices, such as

sensors and actuators. These ﬁles implement the

logic required to operate hardware components.

• Library. External library ﬁles used in the exoge-

nous environment to extend ﬁrmware function-

ality and integrate additional resources, such as

hardware communication support.

• EndogenousEnv. A computational abstraction

providing resources and functionalities to support

agent tasks within the system’s context. It reﬂects

the internal, logical context, enabling agents to in-

teract with the environment directly (Ricci et al.,

2012). This implementation includes references

to the SimulatedEnvironment class and an exten-

sible architecture to include Artifacts in the future,

allowing integration with the CArtAgO platform.

• Artifact. Represents artifacts deﬁned in the envi-

ronment. These components abstract functionali-

ties or resources from the exogenous environment,

enabling agents to interact with them logically and

in a controlled manner. This resource type will be-

come available with the future implementation of

the CArtAgO platform, which provides a founda-

tion for modeling and managing artifacts in MAS

environments.

• SimulatedEnvironment. Additional ﬁles that

conﬁgure or customize the endogenous environ-

ment within a project. These ﬁles may include

speciﬁc deﬁnitions for connecting agents to the

environment or customizing their interaction.

The organization dimension (Organization) en-

compasses the elements responsible for structuring

an Embedded MAS project’s organization, centraliz-

ing deﬁnitions related to agent interactions, roles, and

hierarchies within the system (Boissier et al., 2020).

While the development and implementation of this di-

mension are planned for future work, its importance

lies in supporting organizational frameworks, such as

MOISE, which provide a formal foundation for mod-

eling multi-agent organizations.

The Model of Organization for Multi-Agent Sys-

tems (MOISE) (H

ubner et al., 2002) is a platform

that offers a formal model for representing organiza-

tions in MAS. It is based on three main dimensions:

structure, which deﬁnes roles and hierarchical rela-

tionships among agents; functionality, which speci-

ﬁes the goals and tasks to be achieved; and regulation,

which describes the plans and norms governing agent

actions. The use of MOISE in MAS development

enhances their organization and governance (Bordini

et al., 2007).

The project conﬁguration layer organizes the es-

sential elements required to deﬁne and initialize an

Embedded MAS. It centralizes fundamental conﬁgu-

ration properties and allows the inclusion of a single

conﬁguration ﬁle per project. Figure 14 illustrates the

class diagram for this layer, highlighting the MasCon-

ﬁguration interface and its possible implementations:

Figure 14: Project conﬁguration layer.

ICEIS 2025 - 27th International Conference on Enterprise Information Systems

1042

Mas2j and Jcm.

• MasConﬁguration. An interface extending Pro-

jectFile that abstracts project conﬁguration ﬁles.

It establishes a uniﬁed standard for structuring

the necessary information, facilitating the man-

agement of speciﬁc conﬁgurations.

• Mas2j. Represents project conﬁguration ﬁles in

the .mas2j format, used in projects developed with

Jason Embedded. This type of ﬁle speciﬁes agents

and their basic conﬁgurations, offering an orga-

nized structure for deﬁning and initializing system

components.

• Jcm. Represents project conﬁguration ﬁles in the

.jcm format, applicable to projects that will use

the JaCaMo platform. This ﬁle enables the inte-

gration of agents deﬁned in Jason Embedded with

environmental artifacts and organizational struc-

tures, allowing synchronization across the sys-

tem’s different levels.

The new ﬁle structure implemented in IDE orga-

nizes the elements of Embedded MAS into indepen-

dent dimensions of agents, environment, and organi-

zation. This modular approach allows each dimen-

sion to be represented with speciﬁc ﬁles, facilitating

project management and expansion. The introduction

of a centralized project conﬁguration layer abstracts

the .mas2j and .jcm formats, offering support for both

Jason Embedded and, in the future, JaCaMo.

This reorganization enables a clearer separation

between the system’s various components, improv-

ing internal structure and project clarity. Addition-

ally, dividing elements into distinct ﬁles simpliﬁes

the implementation of new functionalities and inte-

gration with additional tools. With this modular struc-

ture, the development and application of a Git-based

version control system become feasible, allowing for

more speciﬁc and organized tracking of changes. This

restructured ﬁle base prepares IDE to support fu-

ture functionalities, promoting an organization that

reﬂects the requirements of Embedded MAS while fa-

cilitating project maintenance and evolution.

The Domain Service module in ChonIDE imple-

ments ﬁle, project, and path management services

modularly. This chapter details the ProjectFileSer-

vice interface and its implementations, highlighting

the Decorator design pattern, which enables ﬂexi-

ble functionality extension, and the Singleton pattern,

which ensures a single controlled instance of a ser-

vice. It also covers the ProjectService and Project-

PathHandler interfaces and their implementations,

which collaborate to maintain consistency and ex-

tensibility in project element handling. Figure 15

presents the class diagram of these interfaces, their

implementations, and their relationships.

The ProjectFileService interface deﬁnes basic op-

erations such as loading, saving, deleting, and renam-

ing project ﬁles. StandardProjectFileService imple-

ments this interface using ProjectPathHandler to ob-

tain the correct ﬁle paths. For speciﬁc operations with

agent ﬁles, AgentFileService also implements Pro-

jectFileService, ensuring that agent ﬁles are handled

differently, interacting not only with the agent ﬁle it-

self but also with the project conﬁguration layer.

In the ﬁle management service implementation,

the IntercepterProjectFileService acts as a decora-

tor (Gamma, 1995) by delegating operations to Stan-

dardProjectFileService or AgentFileService based on

the type of ﬁle being managed. This approach pro-

vides ﬂexibility in handling different ﬁle types with-

out directly modifying existing services. In IDE,

ProjectPathHandler uses Singleton pattern (Gamma,

1995) through the ProjectPathHandlerManager class

to centralize the deﬁnition of ﬁle and project paths,

Figure 15: File management service module.

A Modularized and Reusable Architecture for an Embedded MAS IDE

1043

ensuring all operations dependent on these paths are

consistent and synchronized.

The Service module structure in IDE organizes

path, project, and ﬁle management modularly. The

ProjectFileService, ProjectService, and ProjectPath-

Handler interfaces, along with their implementations,

provide extensibility and consistency in project ele-

ment handling. This approach simpliﬁes IDE mainte-

nance and evolution, enabling the integration of new

features without compromising the existing structure,

thus ensuring a solid foundation for IDE’s continuous

development.

5 REPRODUCIBILITY

Aiming to ensure the reproducibility of this work, the

source code and an implementation of the new archi-

tecture are available on the paper’s page

6 CONCLUSIONS

This work established a modular architecture for the

chonIDE codebase, enhancing its ﬂexibility and ex-

tensibility to enable software scalability through the

reorganization of its components. Furthermore, a

folder and ﬁle structure was implemented to replace

the previous single-ﬁle project structure, promoting

interoperability with other IDEs and enabling code

versioning—features previously unattainable due to

the proprietary project ﬁle format being manipulable

only within the IDE itself. Thus, it is understood

that with the proposed changes, chonIDE is better

equipped to meet market demands, thereby reducing

software engineering challenges in the context of Em-

bedded MAS.

6.1 Future Works

As future works, the goal is to explore another aspects

of chonIDE’s adaptability to market demands: inte-

gration with Language Servers (LSP) to enable syntax

checking and highlighting, code autocompletion, and

quick assistance; the evolution of the Mind Inspector

into a comprehensive control tool for a running MAS,

allowing developers to insert and modify elements of

agent logic (beliefs, intentions, plans, etc.) through

a more interactive interface; and the implementation

of project code versioning through Git, integrated into

the IDE.

https://papers.chon.group/ICEIS/2025/

modularizedArchChonIDE/

REFERENCES

Boissier, O., Bordini, R. H., Hubner, J., and Ricci, A.

(2020). Multi-agent oriented programming: program-

ming multi-agent systems using JaCaMo. Mit Press.

Bordini, R., H

ubner, J., and Wooldridge, M. (2007). Pro-

gramming Multi-Agent Systems in AgentSpeak using

Jason. Wiley Series in Agent Technology. Wiley.

Bordini, R. H., H

ubner, J. F., and Vieira, R. (2005). Jason

and the golden ﬂeece of agent-oriented programming.

In Bordini, R. H., Dastani, M., Dix, J., and El Fal-

lah Seghrouchni, A., editors, Multi-Agent Program-

ming: Languages, Platforms and Applications, pages

3–37, Boston, MA. Springer US. DOI: 10.1007/0-

387-26350-0 1.

Corporation, O. (2024). Java Development Kit

(JDK). https://www.oracle.com/java/technologies/

javase-downloads.html.

Evans, E. (2004). Domain-Driven Design: Tackling Com-

plexity in the Heart of Software. Addison-Wesley Pro-

fessional, Boston, MA.

Fowler, M. (2002). Patterns of Enterprise Application Ar-

chitecture. Addison-Wesley.

Fowler, M. (2004). Inversion of control containers and

the dependency injection pattern. https://martinfowler.

com/articles/injection.html.

Gamma, E. (1995). Design patterns: elements of reusable

object-oriented software. Addison-Wesley.

ubner, J. F., Sichman, J. S. a., and Boissier, O. (2002).

Moise+: towards a structural, functional, and de-

ontic model for mas organization. In Proceed-

ings of the First International Joint Conference on

Autonomous Agents and Multiagent Systems: Part

1, AAMAS ’02, page 501–502, New York, NY,

USA. Association for Computing Machinery. DOI:

10.1145/544741.544858.

Jennings, N. R. (2001). An agent-based approach for

building complex software systems. Commun. ACM,

44(4):35–41. DOI: 10.1145/367211.367250.

Jesus, V., Lazarin, N., Pantoja, C., Manoel, F., Alves, G.,

Ramos, G., and Filho, J. V. (2022). Proposta de uma

IDE para desenvolvimento de SMA Embarcados. In

Proceedings of the 16th Workshop-School on Agents,

Environments, and Applications, pages 49–60, Porto

Alegre, RS, Brasil. SBC. https://sol.sbc.org.br/index.

php/wesaac/article/view/33425.

Lazarin, N., Pantoja, C., and Viterbo, J. (2023). Towards

a Toolkit for Teaching AI Supported by Robotic-

agents: Proposal and First Impressions. In Proceed-

ings of the 31st Workshop on Computing Education,

pages 20–29, Porto Alegre, RS, Brasil. SBC. DOI:

10.5753/wei.2023.229753.

Pantoja, C., Soares, H. D., Viterbo, J., and Seghrouchni,

A. E. F. (2018). An Architecture for the Development

of Ambient Intelligence Systems Managed by Embed-

ded Agents. In 30th International Conference on Soft-

ware Engineering and Knowledge Engineering, pages

215–220. DOI: 10.18293/SEKE2018-110.

Pantoja, C. E., Jesus, V. S. d., Lazarin, N. M., and Viterbo,

J. (2023). A Spin-off Version of Jason for IoT and

ICEIS 2025 - 27th International Conference on Enterprise Information Systems

1044

Embedded Multi-Agent Systems. In Naldi, M. C. and

Bianchi, R. A. C., editors, Intelligent Systems, pages

382–396, Cham. Springer Nature Switzerland. DOI:

10.1007/978-3-031-45368-7 25.

Pantoja, C. E., Stabile, M. F., Lazarin, N. M., and Sich-

man, J. S. (2016). ARGO: An Extended Jason Ar-

chitecture that Facilitates Embedded Robotic Agents

Programming. In Baldoni, M., M

uller, J. P., Nunes, I.,

and Zalila-Wenkstern, R., editors, Engineering Multi-

Agent Systems, pages 136–155, Cham. Springer. DOI

10.1007/978-3-319-50983-9 8.

Ricci, A., Santi, A., and Piunti, M. (2012). Action and Per-

ception in Agent Programming Languages: From Ex-

ogenous to Endogenous Environments. In Collier, R.,

Dix, J., and Nov

ak, P., editors, Programming Multi-

Agent Systems, pages 119–138, Berlin, Heidelberg.

Springer. DOI: 10.1007/978-3-642-28939-2 7.

Siqueira, E., Ramos, G., Raboni, T., Pantoja, C., and

Lazarin, N. (2024). An

alise Comparativa de um

Prot

otipo de IDE para Desenvolvimento de SMA Em-

barcados. In Proceedings of the 18th Workshop-

School on Agents, Environments, and Applications,

pages 85–95, Porto Alegre, RS, Brasil. SBC. https:

//sol.sbc.org.br/index.php/wesaac/article/view/33458.

Souza de Jesus, V., Mori Lazarin, N., Pantoja, C. E.,

Vaz Alves, G., Ramos Alves de Lima, G., and Viterbo,

J. (2023). An IDE to Support the Development of

Embedded Multi-Agent Systems. In Mathieu, P.,

Dignum, F., Novais, P., and De la Prieta, F., editors,

Advances in Practical Applications of Agents, Multi-

Agent Systems, and Cognitive Mimetics. The PAAMS

Collection, pages 346–358, Cham. Springer Nature

Switzerland. DOI: 10.1007/978-3-031-37616-0 29.

Tennenhouse, D. (2000). Proactive computing. Commun.

ACM, 43(5):43–50. DOI: 10.1145/332833.332837.

Wooldridge, M. (2009). An Introduction to Multiagent Sys-

tems. John Wiley & Sons, Chichester, U.K, 2nd edi-

tion.

Wooldridge, M. and Jennings, N. R. (1995). Intel-

ligent agents: theory and practice. The Knowl-

edge Engineering Review, 10(2):115–152. DOI:

10.1017/S0269888900008122.

Zambonelli, F., Jennings, N. R., and Wooldridge, M.

(2003). Developing multiagent systems: The gaia

methodology. ACM Trans. Softw. Eng. Methodol.,

12(3):317–370. DOI: 10.1145/958961.958963.

Zambonelli, F. and Van Dyke Parunak, H. (2003). Signs

of a revolution in computer science and software en-

gineering. In Petta, P., Tolksdorf, R., and Zambonelli,

F., editors, Engineering Societies in the Agents World

III, pages 13–28, Berlin, Heidelberg. Springer Berlin

Heidelberg. DOI: 10.1007/3-540-39173-8 2.

A Modularized and Reusable Architecture for an Embedded MAS IDE

1045