Multi-Agent Systems (MAS) is to divide the
problem into more concrete aspects that form
different views of the system. The difference
between this proposal and others which already exist
is how these views are defined and built, and how
they are integrated into the MAS development. Each
type of view is described by using a meta-modelling
language which specifies a kind of grammar with
which models are built, known as views. INGENIAS
recognizes five meta-models that describe system
views.
After studying other methodologies, we
developed an analysis with which to identify the
advantages of INGENIAS in comparison with the
other methodologies. First, we concluded that
INGENIAS provides the best support in all the
phases of the lifecycle of an agent-based application,
including its management. Second, INGENIAS
provides a tool support that others do not yet have.
For instance, INGENIAS provides a visual language
for multi-agent systems definition, which is a
process to guide the lifecycle of software
development based on the Rational Unified Software
Development Process (RUP). In addition, the code
generator itself is another tool developed for
INGENIAS. It produces codes according to the
instructions given by the specification of the system.
This tool can be used to generate a code no matter
what agent platform is being used (Pavón and
Gómez-Sanz 2006).
The analysis and design of the recommender
system mentioned in the introduction is described in
the following sections.
3 ANALYSIS AND DESIGN WITH
INGENIAS METHODOLOGY
Before describing the analysis and design it is first
necessary to give a detailed description of the
system that it is going to be developed, in this case a
multi-agent system that must be able to recommend
documents in a comunity.
Software agents must recommend documents to
users that will prevent them from making costly
searches which, on many occasions, do not generate
the expected results. In these communities it is
important to know which users are trustworthy
document sources. A trust model presented in
(Portillo, Soto et al. 2008) is therefore used to make
recommendations and to calculate the trust between
members. The model then uses these trust values to
weight the evaluation values given by users to the
documents once they have used them. The
evaluations made by trustworthy users will therefore
have more importance than the evaluations made by
non-trustworthy users.
Once the kind of system to be developed is
known, system requirements must be extracted.
Moreover, the design requirements specify that each
user is represented in the system by one software
agent and that the communities will be managed by
another software agent.
These requirements are the starting point of the
INGENIAS analysis phase in which requirements
are used to identify use cases that will be modelled
by using interaction models such as the use case
Obtain Recommendation.
Figure 1: Obtain_Recommendation Use case.
Figure 1 shows an example of the modelling of
the Obtain_Recomendation use case through the
use of an interaction model (called
document_recommendation). In this model the goal
of the use case is to Recommend Documents. The
roles that participate in the use case are also
specified, indicating which one initiates the use case
and which one collaborates. In the case of Figure 1
there are three roles: the user (played by a human
being), the recommender and the community
manager (both of which are played by software
agents). It is important to emphasize that these
kinds of diagrams are previously modelled by using
UML collaboration diagrams, and this is indicated
by using the HasSpec Relationship.
The task of specifying use cases by using
interaction models must be carried out for each of
the use cases previously identified. In this case, only
one use case model (that which is most closely
related to the main goal of the system
(recommending documents) is mentioned owing to
space limitations.
ICSOFT 2009 - 4th International Conference on Software and Data Technologies
176