Interface mapping for IDL (IDL code)
For each Interface, ACS generates an IDL file that contains an interface declaration. ACS generates code similar to this:
//=====================================
/// @file Interface1.idl
//=====================================
#ifndef INTERFACE1_IDL
#define INTERFACE1_IDL
#pragma ciao lem "Interface1E.idl"
interface Interface1
{
...
};
#endif
In addition, when used to type an asynchronous Client, each Interface maps to an Implementation element in the appropriate Component Deployment Plan (CDP) file.
The generation of an IDL file for an Interface is derived from the items it owns, properties of the Interface.
Child items:
Reverser Notes: When reverse engineering an interface's attributes, the Reverser will reverse engineer the attribute as a Role if all of the following statements are true:
◦ The IDL attribute's data type can be identified as a class, interface, or component in the code being reverse engineered.
◦ The IDL class, interface or component that is used as a data type is being reverse engineered.
◦ The Reverser cannot match the IDL attribute to an Attribute in the Model.
Other child items are ignored.
Properties:
• If the Description property has a value, ACS generates the Description as a comment at the beginning of the IDL file.
• ACS generates the Name property as the name of the interface.
| ACS may modify the interface name that is added to the code to make it valid for IDL. You can specify the exact interface name to add to the code through the CODE_GENERATION_NAME property of an Interface. |
Other properties are ignored.
Tag Definitions:
The following Tag Definitions are applied to an Interface by the «CORBAInterface» stereotype.
• If the tagged value of the isLocal tag definition is set to TRUE, the interface is generated as a local interface.
Note that if the «Local» stereotype is applied to the Interface, the interface is generated as a local interface.