ASPECS is a step-by-step requirements to code software engineering process based on a meta-model 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 (organizations) 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 meta-model; 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 modeling 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 meta-models and processes were considered, and on the other hand the Janus platform has been selected to implement and deploy holonic multiagent systems (the meta-model of Janus was largely inspired by RIO ??? and its holonic extensions ???,???). After the design of the new process, Janus has been adapted to better fulfill some implementation-level requirements. Starting from this background, the development of the new ASPECS process started from the conception of its underlying meta-model, that is also why this meta-model ???,??? was published before ???. The first objective was thus to obtain a meta-model able to ensure transitions from the analysis phase to implementation by integrating both organization 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 ???,???,??? and the work done by some of the authors in applying this paradigm to agent-oriented design methodologies ???,???,???,???. The specific approach prescribed the definition of the MAS meta-model 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 meta-model is then used as a reference point for identifying the activities that in the process will define the MAS meta-model 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 ???,???,???,???. 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 organizational 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 fulfill the need of modeling goals and agents’ behaviors.


ASPECS Process

The ASPECS process structure (in terms of process meta-model) is based on the Software Process Engineering Meta-model Specification ??? 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 meta-model, 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 meta-model elements.


The life cycle of ASPECS consists in three phases that are briefly described below and illustrated by Figure 1:

  1. System Requirement Analysis: the organizational 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 and Deployment: the description of holons architecture, associated code production and tests and the description of the application deployment.


Figure 1: Road-map of the ASPECS process (Phases/Activities and their goals)


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 Meta-model Elements: the set of MAS meta-model elements (MME) that are defined/related/quoted. In this perspective, three operators have been defined:
  • Define(E): defines the E element of the MAS meta-model.
  • Relate(E1,E2): relates two elements E1 and E2 of the MAS meta-model (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).


Table 1 gives a summary of the process activities and phases; and more detailled in Table 4.


Table 1: Summary of activities and phases goals

Phase Activity Goal of the phase/activity
System Requirements Defining System requirements and identifying organizations
Domain Requirements Description Depicting a functional description of the system by means of use cases.
Problem Ontology Description Capturing the conceptual structure of the problem domain. Description of the system and organizations context.
Organization Identification Clustering several requirements under the responsibility of one entity (organization).
Interactions and Roles Identification Identifying the roles that compose an organization and their interactions.
Scenarios Description Describing sequences of role interactions inside an organization.
Role Plan Dynamical description of roles, specification of their behavior.
Capacity Identification Identifying Capacities and Role dependencies.
Agent Society Defining roles communications, agents and holons architecture
Solution Ontology Description Refining Problem Ontology at a solution level of details.
Agent Identification Identify agent of the system and their responsibilities
Agent Architecture Description Identify capacities associated to agents
Communication Ontological Description Describing conversations between roles in terms of ontology, interaction protocol, content language.
Role Behavior Description Refining the description of a role behavior
Protocol Description Describing newly introduced interaction protocols
Organization Dependencies Description Identifying and describing services, resources, and new capacities. Matching capacities with services.
Role Constraints Identification Identifying roles that can be played simultaneously and scheduling constraints.
Agent Plan Description Describe agent personal plan.
Holarchy Design Associate to each super-holon a government type and describe the various rules used to take decisions. Determine the holonic structure of the system and detail rules governing holon dynamics.
Implementation and Deployment Implementing solution using platform dependent concepts and deploying solution on a given platform
Holon Architecture Define holon abstract architecture(s) according to the chosen implementation platform
Code Reuse Reuse code of previous applications
Code Production of organizations and roles Code each organizations and their associated roles
Organization Test Test each organizations and their roles independently
Code Production of holon Code each holons
Holon Test Test each holon independently
Deployment Configuration Description of the application deployment
Integration Test Test the global behavior of the application


Table 2: System Requirements phase of the ASPECS process

Phase Name Activity Name Goal of this process component Inputs Outputs MAS meta-model Elements (Define, Refine, Relate, Quote)
System Requirements Domain Requirement Description (DRD) Depicting a functional description of the system by means of use cases. Text usage scenarios, interviews with future users and the commissioner DRD Document (Use Case Diagram) Define(Functional Requirements), Define(Non-Functional Requirements), Relate (Functional Requirements, Non-Functional Requirements)
Problem Ontology Description (POD) Capturing the conceptual structure of the problem domain. Description of the system and organizations context. DRD-WP, text usage scenarios,interviews Class Diagram Define(Ontology), Define(Concept), Define(Action), Define(Predicate), Relate(Concept, Concept), Relate(Action, Concept), Relate(Predicate, Concept)
Organization Identification (OID) Clustering several requirements under the responsibility of one entity (organization) DRD_WP, POD_WP, Organizational Design Patterns Use Case Diagram Define(Organization), Quote(Functional Requirement), Quote(Non Functional Requirement), Relate(Organization, Functional Requirement), Relate(Organization, Non-Functional Requirement)
Interactions and Roles Identification (IRI) Identifying the roles that compose an organization and their interactions. Text usage scenarios, OID-WP Class Diagram Define(AbstractRole), Define(Interaction), Relate(Organization, AbstractRole), Relate(Organization, Interaction), Relate(AbstractRole, Interaction)
Scenarios Description (SD) Describing sequences of role interactions inside an organization Text usage scenarios, OID-WP Sequence Diagram Define(Scenario), Quote(Interaction), Quote(AbstractRole), Quote(Relate(AbstractRole, Interaction))
Role Plan(RP) Dynamical description of roles, specification of their behavior OID-WP, IRI-WP, SD-WP Activity Diagram Define(RolePlan), Define(RoleTask), Quote(Role), Relate(RoleTask, AbstractRole)
Capacity Identification (CI) Identifying Capacities and Role dependencies. IRI-WP, RP-WP, SD-WP Class Diagram Define(AbstractCapacity), Relate(AbstractRole, AbstractCapacity), Relate(Organization, AbstractCapacity)


Table 3: Agent Society phase of the ASPECS process

Phase Name Activity Name Goal of this process component Inputs Outputs MAS meta-model Elements (Define, Refine, Relate, Quote)
Agent Society
Solution Ontology Description (SOD) Refining Problem Ontology at a solution level of details. POD-WP, CI-WP, RP-WP Class Diagram Define(Ontology), Define(Predicate), Define(Action), Define(Concept), Relate(Ontology,(Concept, Action, Predicate)), Relate(Concept,Action), Relate(Concept,Predicate)
Agent Identification (AI) Identify and describe agents of the system and their responsibilities DRD-WP, SOD-WP TROPOS Actor and Goal diagrams Define(Agent), Define(Individual Goal), Relate(Agent, Individual Goal)
Agent Architecture Description (ADD) Identify capacities associated to agents CI-WP, SOD-WP, AI-WP Class diagram Relate(Agent, Capacity)
Communication Ontological Description (COD) Describing conversations between roles in terms of ontology, interaction protocol, content language. IRI-WP, SD-WP, CI-WP, SOD-WP Class Diagram Define(Communication), Define(Conversation), Relate(Communication, Predicate), Relate(Communication, Concept), Relate(Communication, Action), Relate(Conversation, Protocol), Relate(Conversation, Language)
Role Behavior Description (RBD) Refining the description of a role behavior RP-WP, CI-WP State Charts Define(AgentAction), Define(AgentRoleState), Quote(AgentRole), Quote(AgentTask), Relate(AgentTask, AgentAction), Relate(AgentRole, AgentTask), Relate(AgentRole, AgentRoleState)
Protocol Description (PD) Describing newly introduced interaction protocols COD-WP, SD-WP Sequence Diagram Define(Protocol)
Organization Dependencies Description (ODD) Identifying and describing services, resources, and new capacities. Matching capacities with services. CI-WP, RBD-WP, SOD-WP Class Diagram Define(Service), Relate(AgentRole, Service), Define(Resource), Define (Capacity), Relate(AgentRole, Resource), Relate(Capacity, Resource), Relate(Capacity, Service)
Role Constraints Identification (RCI) Identifying roles that can be played simultaneously and scheduling constraints. ODD-WP, RBD-WP Class Diagram Relate(AgentRole, AgentRole)
Agent Plan Description (APD) Describe agent’s personal plan AAD-WP, RCI-WP Activity or State Diagram Quote(Agent)
Holarchy Design (HD) Agentification; associate to each super-holon a government type and describe the various rules used to take decisions. Determine the holonic structure of the system and detail rules governing holon dynamics. RCI-WP, ODD-WP, Holon Government Organizational Design Patterns Holonic Cheese-board Text (The answer to the question defined in the holon government template) Define(Holon), Define(Group), Relate(Agent, AgentRole), Relate(Holon, AgentRole), Relate(Holon, Holonic Organisation), Relate(Group, Agent), Relate(Group, Holon), Define(Holonic Role), Define (Government rules)


Table 4: Implementation and Deployment phase of the ASPECS process

Phase Name Activity Name Goal of this process component Inputs Outputs
Implementation Holon Architecture (HA) Define holon abstract architecture(s) according to the chosen implementation platform HS-WP Class Diagram
Code Reuse (CR) Reuse code of previous applications Organizational Pattern, HA-WP Code
Code Production of organizations and roles (OCP) Code each organizations and their associated roles RBD-WP, COD-WP, PID-WP, ODD-WP Code
Organization Test (OT) Test each organizations and their roles independently OCP-WP Test cases
Code Production of holon (HCP) Code each holons HA-WP, HD-WP, OT-WP Code
Holon Test (HT) Test each holon independently HCP-WP Test cases
Deployment Deployment Configuration (DC) Description of the application deployment HT-WP Deployment Diagram
Integration Test (IT) Test the global behavior of the application DC-WP Test cases
This page was last modified on 5 June 2013, at 08:52. This page has been accessed 25,740 times.
Copyright 2010-2017 © IRTES Institute - UPR EA 7274 - Université de Technologie de Belfort-Montbéliard - Privacy policy