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:
- System Requirement Analysis: the organizational description of the problem and the ontological description of the application’s context.
- 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.
- Implementation and Deployment: the description of holons architecture, associated code production and tests and the description of the application deployment.
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.
| 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 |
| 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) |
| 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) |
| 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 |
