Hi everybody,
My name is David, from Metodos y Tecnologia (MTP).
Comparing the Java and ANSI-C mapping for the TriComponenIdType, we have
found the following:
Java
public interface TriComponentId {
public String getComponentId();
public String getComponentName();
public String getComponentTypeName();
public TriPortIdList getPortList();
public boolean equals(TriComponentId port);
}
ANSI-C
typedef struct TriComponentId {
BinaryString compInst;
String compName;
QualifiedName compType;
} TriComponentId;
According to the Java mapping, the TriComponentIdType should have a
reference to the componentÂ’s port list.
According to the ANSI-C mapping, we donÂ’t have this information.
The point is that we are implementing C++ TCI/TRI interfaces, so we are
getting the Java mapping (OO) as reference for the C++ class methods and the
ANSI-C mapping as reference for the C++ class attributes/types. In the case
of the TriComponentId we have to choose between implement the
“getPortList()” method (adding a TriPortIdListType reference in the class)
or donÂ’t implement it (following the information from the ANSI-C).
By the way, implementing the TriComponentIdType following the Java mapping
(reference to TriPortIdListType) leads to a circular reference (always hard
to manage):
TriComponentIdType --> TriPortIdListType --> TriPortIdType -->
TriComponentIdType
We think the best solution to break this loop is removing the reference to
the TriPortIdListType from the TriComponentIdType (as ANSI-C mapping
propose), because the TriPortIdType --> TriComponentIdType relationship is a
must for the triCommunication interface in order to map TSI ports and
components.
Comments are welcome!
Regards,
David DÃaz RodrÃguez
Computer Engineer
Senior SW Development Consultant
Tel.: (+34) 91 353 15 64 (Ext. 120)
Fax: (+34) 91 359 61 79
Métodos y TecnologÃa (MTP)
Paseo de la Castellana, 182 10º
28046 - Madrid, Spain
www.mtp.es