Revenir à la page d'accueil
Plan du site   |   Plan d’accès   |   UTBM
Projets Européens
Réseaux d'Excellence
Projets Nationaux
Contrats Industriels
Projets thématiques
    ASPECS Methodology
       A quick overview of ASPECS
       System Requirements Analysis
       Agent Society Design
       Comparisons with existing Agent-Oriented Methodologies
Accueil > Activités et projets > Projets thématiques > ASPECS Methodology > A quick overview of ASPECS
A quick overview of ASPECS

A quick overview of ASPECS

ASPECS is a step-by-step requirements to code software engineering process based on a metamodel which defines the main concepts for the proposed HMAS analysis, design and development. It integrates design models and philosophies from both object and agent oriented software engineering (OOSE and AOSE) and is largely inspired by the PASSI and RIO approaches. The target scope for the proposed approach can be found in complex systems and especially hierarchical complex systems. The main vocation of ASPECS is towards the development of societies (organisations) of holonic (as well as not-holonic) multiagent systems.

ASPECS Requirements

Several key aspects have be taken into account when designing a software development process: its intended audience and stakeholders, its components or activities, its underlying metamodel; the work products it delivers and the associated languages that it uses to document or implement them.

The target audience of ASPECS is composed of researchers and skilled practitioners interested in complex systems modelling and complex software systems development.

The conception of ASPECS was started from two opposite directions that constitute the background of this work: on one hand, the RIO and PASSI metamodels and processes were considered, and on the other hand the Janus platform has been selected to implement and deploy holonic multiagent systems (the metamodel of Janus was largely inspired by RIO [39] and its holonic extensions [62, 63]). After the design of the new process, Janus has been adapted to better fulfil some implementation-level requirements. Starting from this background, the development of the new ASPECS process started from the conception of its underlying metamodel, that is also why this metamodel [18, 61] was published before [18]. The first objective was thus to obtain a metamodel able to ensure transitions from the analysis phase to implementation by integrating both organisational and holonic related concepts.

After that the construction of the new process started; it has been based on concepts coming from the Situational Method Engineering[8, 38, 64] and the work done by some of the authors in applying this paradigm to agent-oriented design methodologies [17, 20, 21, 67]. The specific approach prescribed the definition of the MAS metamodel underlined by the design process on the basis of the new process requirements (intended users, class of problems to be solved, available/selected implementation platforms and so on). This metamodel is then used as a reference point for identifying the activities that in the process will define the MAS metamodel elements in the proper way (and order).

The resulting ASPECS process now benefits from experiments and theoretical studies done on PASSI and Agile PASSI, its two eldest sisters [12, 13, 16, 19]. Just like them, ASPECS is based on an iterative process, as it is for other widely accepted approaches in both the agent- and object-oriented contexts.

Concerning its work products, ASPECS uses UML as a modeling language but because of the specific needs of agents and holonic organisational design, the UML semantics and notation are used as reference points, and they have been extended (mainly with the definition of new profiles); in fact UML diagrams are often used to represent concepts that are not completely considered in UML and/or the notation has been modified to better fulfil the need of modelling goals and agents’ behaviours.

ASPECS Process

The ASPECS process structure (in terms of process metamodel) is based on the Software Process Engineering Metamodel Specification [72] proposed by the OMG. At the core of SPEM is the idea that a software development process is a collaboration between abstract active entities, called Roles, that perform operations, called Activities, on concrete, tangible entities, called Work Products. SPEM clearly separates reusable Method Content from its application in Processes. More precisely a process model is built out of Process Elements. Each Process Element can be specialized to describe one aspect of a software engineering process. According to this metamodel, the software process of ASPECS is based on three main levels: Phases, Activities and Tasks. A Phase delivers a composite work product (composed of one or more documents that can belong to different work product
types), a phase is composed of a number of activities that are in turn decomposable into tasks. An Activity delivers a main work product (like a diagram or a text document) and it is composed of a number of Tasks. A task contributes to the production of a work product (usually by delivering a part of it), and it instantiates/relates/refines MAS metamodel elements.

The life cycle of ASPECS consists in four phases that are briefly described below:

  1. System Requirement Analysis: the organisational description of the problem and the ontological description of the application’s context.
  2. Agent Society Design: the design of the agent society that is able to provide a solution to the previously described problem, and a refinement of the application context description.
  3. Implementation: the description of holons architecture, associated code production and tests.
  4. Deployment: the description of the application deployment.

The different phases of ASPECS

The description of the ASPECS software development process has been split in two different levels: the first one describes the process at the phase level, the second one reports the sub-cycle associated to each phase. Each of these phases and their associated activities will be detailed in the following sections. Descriptions will be based on the following template:

Goal the goal of the activity.
Input: its input work product(s).
Output: its output work product(s) and the notation(s) suggested for designing it.
MAS Metamodel Elements: the set of MAS metamodel elements (MME) that are defined/related/quoted. In this perspective, three operators have been defined:

  • Define(E): defines the E element of the MAS metamodel.
  • Relate(E1,E2): relates two elements E1 and E2 of the MAS metamodel (defines the relationship among them).
  • Quote([E,R(E1,E2)]): reports a previously defined E element or relationship R between E1 and E2.

Work to be done: the description of the work to be done.
Methodological Guidelines: the associated guidelines to help the designer in correctly performing the work (when available).
Example: An instantiation of the current process fragment on a concrete example.

In each activity, the related concepts of the metamodel will be described. By definition a metamodel is a model of a model, and it provides an explicit representation of the constructs and rules needed to build specific models within a domain of interest. As PASSI, the ASPECS metamodel introduces three domains. The first is the problem domain dedicated to the description of a problem independently of a specific solution and it is used in the first phase dedicated to System Requirement Analysis, that is described in section 4 (see figure 1). The second is the agency domain which introduces agent concepts to describe an agent solution on the basis of the elements of the problem domain, and it is related to the design of the Agent Society (see section 5, figure 17). The solution domain is the third and last one; it includes the elements used to implement at the code level the solution described in the agency domain. The implementation and deployment phases are based on the concepts introduced in this last domain and are detailed in section 6 (see figure 28). A complete description of the ASPECS metamodel can be found in [18].

Throughout the description of the ASPECS process, an example is used to briefly illustrate each activity. This example intends to model a simulator for the FIRA Mirosot Robot soccer competition. This competition involves two teams of five autonomous robots playing a game similar to soccer. This is a classical example where real-time coordination is required. It constitutes a well-known benchmark for several research fields, such as MAS, image processing and control.

  90010 Belfort cedex - Tél : +33 (0)3 84 58 33 19 - Fax : +33 (0)3 84 58 33 42 - Mentions légales