Writing a Code Generator in Java (Continued)

Internal Object Model
According to the flow of the proposed architecture, we should start with the importer. However, it would be very tough to explain and show a real example of an importer implementation when the IOM is still unknown because the importer creates and uses the IOM classes. Therefore, let's have a look first at the IOM.

The internal representation of the code generator is the most important part, and the one that should never change. What can be imported and exported depends on a proper design of this module. A good strategy for designing an effective IOM is borrowing UML concepts. Basically, the internal model can be an object-oriented design implementation of the structure of a UML model. Therefore, you can model a set of classes and associations representing UML classes, attributes, operations, parameters, and associations. It might sound a little bit weird, but what we are going to do is design UML features and rules by using UML itself.

As a convention, IOM classes start with the IOM prefix. Figure 2 shows a class diagram of a very simplified IOM. The IOMClass class models a UML class. It has an aggregation with the IOMAttribute and IOMOperation classes because classes have attributes and operations. Since operations have parameters, an aggregation is modeled between the IOMOperation and the IOMParameter classes. The IOMAssociation class represents a UML association. It has two roles (start and end) that are modeled by the IOMRole class. Then, that last class has an association with the IOMClass class (involved), which represents the start or the end class of the UML association.

Although this design is very simple, it will give you an idea about how to implement a fully functional IOM. In a real context, each class should provide specific attributes that somehow will drive the code generation. For example, for the IOMClass class you specify these attributes: name; stereotype; visibility; type (abstract, transient, persistent); and documentation. In addition, important aspects such as base classes, derived classes, exception classes, and packages must be supported by adding new classes and associations to the model.

Listing 1 provides a basic implementation of the IOMClass class. It has just two attributes: name (the name of the class) and stereotype (the UML associated stereotype). The aggregations with the IOMAttribute and IOMOperation classes are implemented by two ArrayList (attributes and operations) and related get/add methods: getAttributes(), addAttribute(), getOperations(), and addOperation(). The class also contains the getMyAssociations() method that returns all the IOMAssociations in which the class is involved as a start or end role. Using a similar approach, you can also implement all the other IOM classes.

The root class of the model is IOMController, which is implemented in Listing 2. It contains and provides the possibility of access to the instances of IOMClass and IOMAssociation involved in the model. In addition, the IOMController class implements the queryClass() method that may be useful to search a class by name. Importers and exporters start from that class respectively to create the IOM and to read metadata from it to write the output.

The final installment will look specifically at the importer and exporter interfaces, and then conclude with the use of multiple exporters, manual implementation, and templates.

About the Author
Giuseppe Naccarato has a degree in computer science and works as software developer for an IT company based in Glasgow (UK). His main interests are J2EE- and .Net-related technologies. Contact Giuseppe at .