Subsections

CCM Metamodel Library API

This chapter describes how to use the CCM metamodel library (written in Java) to create a CCM model in memory. The chapter also illustrates how to navigate in a CCM model to get some information about its entries. The library is strongly based on chapter 8 of the CCM specification, so it would be useful to have a copy of the specification next to you.

Provided you have a CCM Tools source tree handy, there is also javadoc documentation in the doc/api directory that can be used as an API reference.

Implementation details

The CCM metamodel library is separated into two parts. These two parts represent the classic and the component based parts of the IDL. The Base IDL contains all classes to model the classic CORBA IDL syntax. The ComponentIDL contains the CCM extensions from the CORBA component model to model components, homes, factories, and so on.

These two parts are available in the ccmtools.jar file, or as individual source code files. To use the library, the ccmtools.jar file needs to be added to the Java CLASSPATH environment variable. Programs using the library need to include the import statements shown in Example 2.2.1.

Based on the CCM metamodel specification, this implementation defines an interface for every class in the metamodel. The name of the interface is the same as the name of the class, with an `M' prepended. For example, the interface for the HomeDef class in the metamodel is defined show in Example 2.2.2.

$\begin{Example} % latex2html id marker 287\begin{lrbox}{\fmbox}\begin{minipage... ...}\fbox{\usebox{\fmbox}}\caption{Definition of MHomeDef interface.} \end{Example}$

To use the metamodel library, there must be an implementation of the defined interface functionality. So there is an implementation class for every interface. The implementation classes have the same name as the interface, with the string `Impl' appended. For example, the implementation class for HomeDef is defined as shown in Example 2.2.3.

It is good Java programming style to use an interface--not the implementation class--to define the type of an object. This allows for multiple realizations of a given interface. (The CCM Tools only define one implementing class for each metamodel interface, but that is what we like to refer to as a ``technicality.'') So, for example, a CCM metamodel library client application should create an instance of HomeDef like so: MHomeDef myHome = new MHomeDefImpl();.

For debugging, you can use the toString() method of every implementation class to get information about the specific object. All toString() methods in the CCM metamodel library start with interface type, followed by a colon (:). To use these methods, just use a metamodel object in a printing context: System.out.println(myHome);.

Access to attributes

Metamodel classes may contain attributes whose types are boolean, non-boolean or an array. Each attribute in a metamodel class is mapped to a set of accessor methods in the library.

Access to boolean attributes

If a metamodel class contains a boolean attribute, the attribute name always starts with `is'. Boolean attributes are always accompanied by a pair of get/set accessor functions. The get-method has the same name as the attribute. The set-method replaces `is' with the prefix `set'. For example, the isAbstract attribute in the InterfaceDef class of the metamodel is mapped to the code shown in Example 2.2.4. The implementation class of InterfaceDef is shown in Example 2.2.5.

$\begin{Example} % latex2html id marker 323\begin{lrbox}{\fmbox}\begin{minipage... ...oolean--attribute access functions in the InterfaceDef interface.} \end{Example}$

$\begin{Example} % latex2html id marker 333\begin{lrbox}{\fmbox}\begin{minipage... ...ribute access functions in the InterfaceDef class implementation.} \end{Example}$

Access to non-boolean attributes

If a metamodel class contains a non-boolean attribute (for example, a String or Long), the get-method has the prefix `get' followed by the capitalized name of the attribute. The set-method has the prefix `set' followed by the capitalized name of the attribute. For example, the identifier attribute in the OperationDef class of the metamodel is mapped to the code shown in Example 2.2.6. The implementation class of OperationDef is shown in Example 2.2.7.

$\begin{Example} % latex2html id marker 353\begin{lrbox}{\fmbox}\begin{minipage... ...olean--attribute access functions for the OperationDef interface.} \end{Example}$

$\begin{Example} % latex2html id marker 363\begin{lrbox}{\fmbox}\begin{minipage... ...n{Non--boolean--attribute access implementation for OperationDef.} \end{Example}$

Access to array attributes

If a metamodel implementation class contains array attributes, then the class includes the standard get- and set-methods for the array attribute. The class stores array attributes internally in either a Set or a List, depending on the nature of the attribute. The class also includes accessor methods for direct access to an attribute at a specific position within the array. For example, the members attribute in the EnumDef class of the metamodel is mapped to the code shown in Example 2.2.8. The implementation of EnumDef is shown in Example 2.2.9.

$\begin{Example} % latex2html id marker 379\begin{lrbox}{\fmbox}\begin{minipage... ...ption{Array--attribute access functions in the EnumDef interface.} \end{Example}$

Access to associations

An association is a link between two classes. Each association in the metamodel has two roles, where each role has a name and a multiplicity. The role attached to an element is the direct role, and the role on the other side of the association is called the opposite role. There are three different types of roles in the CCM metamodel: reference, bag, and list. The three different role types are classified based on the multiplicity and sort order of the opposite role. Each type of association has its own set of navigation methods, which are described below.

Reference role

A reference role has a multiplicity of 1 or 0..1. These roles have the same access methods as non-boolean attributes. For example, the association between the Typed and IDLType class of the metamodel is mapped to the code shown in Example 2.2.10. The implementation of EnumDef is shown in Example 2.2.11.

$\begin{Example} % latex2html id marker 420\begin{lrbox}{\fmbox}\begin{minipage... ...ion{Reference attribute access functions in the MTypedImpl class.} \end{Example}$

Bag role

A bag role has an unordered multiplicity different from 1 or 0..1. Bag roles refer to attributes stored internally as Sets, where sort order is not important. For example, the association between the Container and Contained classes of the metamodel is mapped to the code shown in in Example 2.2.12. The implementation of EnumDef is shown in Example 2.2.13.

$\begin{Example} % latex2html id marker 439\begin{lrbox}{\fmbox}\begin{minipage... ...}}\caption{Bag role access functions in the MContainer interface.} \end{Example}$

$\begin{Example} % latex2html id marker 449\begin{lrbox}{\fmbox}\begin{minipage... ...bute access functions in the MContainerImpl implementation class.} \end{Example}$

List role

A list role has an ordered multiplicity other than 1 or 0..1. List roles refer to attributes stored internally as Lists, where sort order is important. Thus, these roles have the same set of access functions as ordered array attributes. For example, the association between the OperationDef and ParameterDef classes is mapped to the code shown in Example 2.2.14. The implementation of EnumDef is shown in Example 2.2.15.

$\begin{Example} % latex2html id marker 468\begin{lrbox}{\fmbox}\begin{minipage... ...t role attribute access functions in the MOperationDef interface.} \end{Example}$

$\begin{Example} % latex2html id marker 478\begin{lrbox}{\fmbox}\begin{minipage... ...t role attribute access functions in the MOperationDefImpl class.} \end{Example}$

2003-11-09