The scenario presented in this chapter is a good example to illustrate that the EMADS approach offers a simple way to incorporate existing methods and data sources into a MADM framework and how new DM tasks are wrapped and incor- porated. This section looks at what components (agents) are affected when new requirements are added and the extensibility of those components.
5.7.1
Incorporating New Data Source
In the current architecture of EMADS, a single data agent controls each separate data source. The data agent in-turn encapsulates and relies on an instance of an agent class. Thus, in order to bring a new data source into the system, a new
data agent must be instantiated. It must also register with the system to ensure the other agents are aware of its existence and the data source can be utilised to fulfil system goals.
In the case of data agents, there is no code required to create a new data agent and introduce it to EMADS. This is achieved through the data wrapper graphical user interface (GUI) as described in Chapter 4, Subsection 4.4.3. The user must use the GUI to refer to the data source location (file path). Then the wrapper creates a new data agent that will represent the data source as it is introduced to the system.
5.7.2
Incorporating New DM algorithms
In order to bring a new DM algorithm into the EMADS system, a new DM agent must be instantiated with the two required components, namely a DM wrapper and DM algorithm. The new DM agent must also be registered with the system to ensure that other agents are aware of its existence and so that the DM algorithm can be utilised to fulfil DM requests.
The independence of the DM technique comes from the fact that the wrapper agents act only as interfaces, to the DM algorithms, to receive requests and pass back results. Because of this, the only code required to create a new DM agent and “introduce” a new DM algorithm becomes a one line instantiation as shown below:
<Algorithm Class Name>instanceName = new<Algorithm Class Name>();
The DM wrapper contains all code required to interface with the DM algo- rithm. In order to ensure all new DM algorithms can communicate in the system, an abstract interface was created (i.e. the mining interface, described in Chapter 4, Subsection 4.4.2). Any new DM algorithm class must extend this abstract interface and implement the abstract methods it includes.
5.7.3
Incorporating New DM Tasks
Task agents, that perform DM tasks, are introduced into EMADS using a pre- defined abstract task agent class (Task Wrapper), described in Chapter 4, Sub-
section 4.4.1. Because the task wrapper is a subclass of the abstract task agent class, any task agent subclass includes all the logic and methods that allow it to communicate within the system which gives it the flexibility to be used by other agents.
It is important to note that the parent abstract task agent class does not ensure or provide any specific methods in the data mining process. Any sub- class can include any other methods or algorithms that would provide the code needed or desired for particular DM task. Because DM algorithms are task spe- cific, these classes allow for any new methods or logic to be implemented, while retaining the ability to communicate with the system through the parent task agent. The parent abstract task agent class enforces the minimum system-specific method implementation possible by providing most of the generic methods (e.g.
“getDataAgents()”, and “getMiningAgents()”) and yet ensures the flexibility for expansion. The task agent abstract class is presented in Chapter 4, Section 4.1.
For example, when the meta ARM task agent was incorporated, the declara- tion code in the meta ARM agent class was as follows:
public class ARMTaskAgent extends TaskAgent
5.7.4
Registering New Agents
To complete the incorporation of a new agent into the EMADS system, the facilitator agent must be aware it exists. The facilitator agent is made aware of any new agent upon its registration (discussed in Chapter 3, Subsection 3.3.5). Once it is aware of the addition, the task agent is the only remaining agent affected. The task agent is directly affected as it is responsible for tasking all useful data agents in fulfilling a data mining request. Every time a data mining request is made, the task agent queries the facilitator agent for all useful agents to serve the request. Once a new agent is registered, it can be returned (and hence be visible) to the task agent, by the facilitator, for communications. The task agent does not maintain a “memory” of agents that are in the system from request to request. The registration of new agents has been made as easy as possible by placing all registration method implementations in the agent wrapper class. Registration then becomes one line entry “this.register(agentName, agentType)”
in the “setup()” method of the agent. The facilitator agent is notified of the presence through the registration process. By reducing the otherwise complex registration process to one line, a great deal of simplicity is introduced into the extension process from the view point of the agent creator.
For example, when the Meta ARM DM agent was created, the agent’s register method was called as follows:
t h i s. r e g i s t e r ( ”ARMAgent” , ” F r e q u e n t I t e m S e t s ” ) ; The registration method code is as follows:
// use f a c i l i t a t o r a g e n t d e s c r i p t i o n
DFAgentDescription dfd = new DFAgentDescription ( ) ;
// add t h e a g e n t name t o t h e f a c i l i t a t o r a g e n t d e s c r i p t i o n dfd . setName ( getAID ( ) ) ; // p r e p a r e t h e a g e n t s e r v i c e d e s c r i p t i o n S e r v i c e D e s c r i p t i o n sd = new S e r v i c e D e s c r i p t i o n ( ) ; // s e t t h e a g e n t t y p e and name sd . setName ( agentName ) ; sd . setType ( agentType ) ; dfd . a d d S e r v i c e s ( sd ) ; try { // r e g i s t e r t h e a g e n t ( s e r v i c e s ) i n t h e y e l l o w p a g e s DFService . r e g i s t e r (this , dfd ) ; } catch ( FIPAException f e ) { f e . p r i n t S t a c k T r a c e ( ) ; }