Soleres-HCI

Soleres-HCI

Trading in Soleres-HCI
 
 
Contents
 
1. Model-Driven Architecture perspective
2. CIM meta-model: Trader
3. CIM model: Trader
4. PIM meta-model: informal class diagram
5. PIM model: informal class diagram of the trader
6. Model to model transformation
6.1. Trader transformation
6.2. Lookup interface transformation
6.3. Register interface transformation
6.4. Admin interface transformation
6.5. Link interface transformation
6.6. Proxy interface transformation
7. Model to text transformation
7.1. Class transformation



1. Model-Driven Architecture perspective

For implementing the trading agent, we follow a Model-Driven Engineering (MDE) perspective based on the classical Model-Driven Architecture (MDA) of the OMG. In this perspective, the trader model stays the three stages of the MDA: CIM/PIM/PSM (see Figure 1). A trader meta-model (MM) is defined for each stage, which describe the way to generate a diagramatical model (UML) of the trader.   



Figure 1: MDA steps of the trader views.
 
Contents
 
 
 
 
 
2. CIM meta-model: Trader
 
Figure 2 shows the meta-model of the trader. It only shows the concepts –Trader (with its parameters) and its five interfaces, Lookup, Register, Admin, Link and Proxy– and the relations between them that we want to model.

 

  Figure 2: Meta-model of the trader.
 
Contents
 
 
 
 
 
3. CIM model: Trader
 
Figure 3 shows the CIM trader model with its five interfaces. We have also used the GMF/Eclipse to develop a tool for documenting CIM trader models. We use the OCL language for describing the semantical restrictions of a trader. Some examples of these restrictions are:
 
      If the trader implements the register interface, it must implement the lookup interface too.
       If the trader implements the admin interface, it must implement the register interface too.
       If the trader implements the link interface, it must implement the admin interface too.
       If the trader implements the proxy interface, it must implement the admin interface too.
       The value of the parameter def_search_card must be a value between 0 and 2147483647.
       ...
 
 


Contents
 
 
 
 
 
4. PIM meta-model: informal class diagram
 
Figure 4 shows a piece of the informal class diagram meta-model based on UML. This class diagram is informal because it doesn’t represent all the elements of the UML class diagram. It only represents packages, classes, relations between them, etc. PSM meta-model (formal class diagram) represents all concepts of the UML class diagram.
 



Figure 4: A piece of the informal class diagram meta-model.
 
Contents
 
 
 
 
 
5. PIM model: informal class diagram of the trader
 
Figure 5 shows the PIM trader model: a partial class diagram. We can see in this figure how the five interfaces of the trader implement a functional interface and these functional interfaces extend other abstract interfaces. Other new classes, like OfferRepository or LinkRepository, appear too.
 


 
Figure 5: Informal class diagram model of the trader.
Contents
 
 
 
 
 
6. Model to model transformation
 
To translate a model into views (stages), we use meta-model-transformation techniques. In our case, we use ATL (ATLAS Transformation Language) for implementing the transformations of the trader. This language provides declarative and imperative constructs. The declarative part of ATL is based on rules. Such rules consist of a source pattern matched over source meta-models and of a target pattern that creates target meta-models for each match.
 
Figure 6 shows a short piece of the ATL code for the transformation CIM/PIM of one of the five interfaces of a trader agent: the Lookup interface. The transformation of the others interfaces is similar to this one.
 



Figure 6: A piece of the ATL model to model transformation.
 
 
The next sections show graphically the elements that are transformed from the trader model to the informal class diagram model.
 
Contents
 
 
 
 
 
6.1. Trader transformation
 
Figure 7 shows the Trader transformation. We can see that the Trader element in the trader model is transformed to the Trader class in the informal class diagram model. All packages, the trading abstract interfaces (TraderComponents, SupportAttributes, ImportAttributes and LinkAttributes), necessary classes (like OfferRepository or LinkRepository) and some relations are generated too.
 



Figure 7: Trader transformation.
 
Contents
 
 
 
 
 
6.2. Lookup interface transformation
 
Figure 8 shows the Lookup interface transformation. We can see that the trader Lookup interface implements the functional Lookup interface, which moreover extends the TraderComponents, SupportAttributes and ImportAttributes abstract interfaces.
 



Contents
 
 
 
 
 
6.3. Register interface transformation
 
Figure 9 shows the Register interface transformation. We can see that the trader Register interface implements the functional Register interface, which moreover extends the TraderComponents and SupportAttributes abstract interfaces.



 
Figure 9: Register interface transformation.  
 
 
 
 
 
6.4. Admin interface transformation
 
Figure 10 shows the Admin interface transformation. We can see that the trader Admin interface implements the functional Admin interface, which moreover extends the TraderComponents, SupportAttributes, ImportAttributes and LinkAttributes abstract interfaces.
 


 
Figure 10: Admin interface transformation.
 
Contents
 
 
 
 
 
6.5. Link interface transformation
 
Figure 11 shows the Link interface transformation. We can see that the trader Link interface implements the functional Link interface, which moreover extends the TraderComponents, SupportAttributes and LinkAttributes abstract interfaces.



 
Figure 11: Link interface transformation.
 
Contents
 
 
 
 
 
6.6. Proxy interface transformation
 
Figure 12 shows the Proxy interface transformation. We can see that the trader Proxy interface implements the functional Proxy interface, which moreover extends the TraderComponents and SupportAttributes abstract interfaces.



 
Figure 12: Proxy interface transformation.
 
Contents
 
 
 
 
 
7. Model to text transformation
 
At the end, Java code generation from PSM trader models can be obtained from a parser written in MOFScript.
 
Figure 13 shows a short piece of the MOFScript code for the transformation of the classes from the formal class diagram model of the trader to Java classes.
   



Figure 13: A piece of the MOFScript model to text transformation.
 
Contents
 
 
 
 
7.1. Class transformation
 
Figure 14 shows an example of the Trader and Lookup classes Java code (Trader.java and Lookup.java, respectively) generated automatically.