iQgen Documentation

You can install iQgen on any machine capable of running a Java Development Kit (JDK) version 1.3 or higher. iQgen has been successfully tested on the following platforms:

Before you install iQgen, you should have a working Java Development Kit (JDK) installation on your system.

You can get the JDK from Sun's web site at http://www.java.com/.

iQgen uses XMI as its input format. Specifically, iQgen has been tested against the XMI exported by the following CASE Tools:

The UML profile for Tutorial 1 is extremely simple - essentially, it doesn't use any stereotypes or tagged values at all.

Tutorial 1 uses the model depicted in the figure below. It will not result in a complete application, but in the end you will have source code which can be compiled and you will have obtained a deeper knowledge of how to develop templates.

Figure 2.1. Tutorial 1 packages

Figure 2.2. Tutorial 1 dependencies class diagram

To give you an overview of the templates in Tutorial 1, here's an overview table with some short comments.

XMI, like many other standards, is unfortunately not a guarantee for interoperability. Different CASE tools export to XMI differently, and this can lead to interoperability problems. iQgen tries to minimize these by streamlining the differences by means of the MetaModelFacade API. Nevertheless, iQgen allows you to access everything that your CASE tool has exported. If you need to make sure that you can change CASE tools in the future, we strongly encourage you to use the MetaModelFacade as much as possible.

iQgen uses an embedded Java Server Pages (JSP) 1.1 engine to execute your templates. If you are familiar with JSP syntax, developing templates with iQgen should be a piece of cake. However, as not everybody can be fluent in JSP, we will give a short introduction.

A JSP's content is a mixture of literals, directives, declarations, scriptlets, and actions. Sun's JSP syntax card gives an excellent overview of which syntactic elements are legal in a JSP. The following paragraphs cover the most important of these elements. If you are familiar with JSP, you may skip this section and continue with how JSP are used in iQgen.

<%! declaration; [ declaration; ]+ ... %>

<%! public java.util.Date getDate() { return new java.util.Date(); } %>

<%@ page import="{package.class|package.*}, ... " %>

<%@ page import="java.util.*,java.net.URL" %>

<%@ page extends="package.class" %>

<%@ page extends="com.innoq.generator.jsp.JspBase" %>

<%= any kind of Java expression %>

<%= new java.util.Date() %>

<%= i>100 ? "i is greater  than 100" : "i is not greater than 100" %>
<%=someObject.someMethod() %>

<% code fragment of one or more lines %>

<%
// this is a comment in Java code
// first scriptlet
for (int i=0; i<100; i++) { %>
   Number: <%=i%>
<%
// second scriptlet
} %>                    

<%@ include file="relativeURL" %>

<%@ include file="copyright.txt" %>
<%@ include file="imports.jsp" %>                    

<%@ taglib uri="taglibURI" prefix="prefix" %>

<tagPrefix:tagName attribute="value"+... />
<tagPrefix:tagName attribute="value"+... >
...
</tagPrefix:tagName>                    

iQgen uses JSP for two purposes:

From Model Element to Template

As you know, a model consists of different model elements such as classes, interfaces, associations, diagrams and so forth. Usually a single model element cannot be mapped one to one to a generated file. Instead often a single model element leads to the generation of multiple files, e.g. a SQL script, a configuration file, a deployment descriptor and a couple of classes. Therefore you need to specify which files should be generated for a given model element. To allow you to specify this in a very flexible and powerful way, this is done with a special JSP - the file main.jsp - a.k.a. the master template.

There are three things you need to do, to write your own main.jsp:

• Extend the class com.innoq.generator.jsp.JspMain

• Implement the method public String[] getTemplates(MBase)

• Implement the method public String getName()

So the most basic main.jsp looks like this:

<%@ page extends="com.innoq.generator.jsp.JspMain"
         import="ru.novosoft.uml.MBase" %>
<%!
/**
 * For performance reasons this array is declared as static
 * final and can be reused for every invocation of getTemplates.
 */
private static final String[] TEMPLATE = {"template.jsp"};

/**
 * Returns the names of the templates to execute for a specific
 * model element.
 *
 * @param element The model element to return the template names for
 * @return Array of template names for a element
 */
public String[] getTemplates(MBase element) {
   return TEMPLATE;
}

/**
 * Name of this modelelement-template mapping.
 */
public String getName() {
   return "My first main.jsp";
}
%>                        

This main.jsp would return the name of the template template.jsp for every model element. Of course this only makes sense in the most simple case. You cannot to generate a SQL script and a Java class file for a persistent object with a single template. Our next example shows a slightly more complex, but a lot more realistic mapping:

<%@ page extends="com.innoq.generator.jsp.JspMain"
         import="ru.novosoft.uml.MBase" %>
<%!
private static final String[] PERSISTENT = {"class.jsp", "drop_and_create.jsp"};
private static final String[] INTERFACE = {"interface.jsp"};
private static final String[] DEFAULT = {"class.jsp"};

public String[] getTemplates(MBase element) {
   String s = getMetaModel().getStereotype(element);
   String name = getMetaModel().getName(element);
   if ("Persistent".equals(s)) {
      return PERSISTENT;
   } else if (getMetaModel().isInterface(element)) {
      return INTERFACE;
   } else {
      return DEFAULT;
   }
}

public String getName() {
   return "My second main.jsp";
}
%>                        

Instead of always returning the same template name for every model element, we return PERSISTENT for all model elements marked with the stereotype Persistent, INTERFACE for all interfaces and DEFAULT for all other madel elements. This allows us to generate SQL scripts with the template drop_and_create.jsp and class files with class.jsp for all persistent madel elements. All other elements lead to the generation to either an interface or a class file.

Let's look how this is done in detail. In every iQgen JSP you can obtain access to the model by invoking the method getMetaModel(). This will return an object of the type com.innoq.generator.metamodel.IMetaModelFacade, which can help you inspecting the current modelelement. The three methods we use in this example are getStereotype(MBase), getName(MBase), and isInterface(MBase). Additionally the metamodel offers many more methods to obtain detailed information about the current element. All methods are covered in the API reference section.

So far we can invoke templates for and with specific model elements. Often some templates need only be invoked once per model and even without a specific model element. Such cases can be covered with the method public String[] getPostprocessTemplates(). Just overwrite this method in your main.jsp to provide the names of all templates that should be executed after all model element-specific templates have been executed:

<%@ page extends="com.innoq.generator.jsp.JspMain"
         import="ru.novosoft.uml.MBase" %>
<%! [...]
private static final String[] POST = {"build.jsp"};
public String[] getPostprocessTemplates() {
   return POST;
}
%>                        

Our example always returns the name of the template build.jsp which generates an XML file that can be used as an Ant build script. Another useful application of this feature is a template for deployment descriptors.

There are several hook methods you can overwrite to control your generation process. The following sequence diagram should help you to get an overview about the calling order. MyJspMain means your JspMain specialization. The writeToFile method should be used very carefully and at the end of this method you must call super.writeToFile(filename, inoutstream).

Figure 1: JspMain Sequence

For a complete description of JspMain 's API, take a look at the API reference section page.

<%@ page import="ru.novosoft.uml.MBase,java.util.Collection,java.util.Iterator"
         extends="com.innoq.generator.jsp.JspBase" %>
<%@ taglib uri="iqgen" prefix="iqgen" %>
<%! private String getClassname() {
   return getMetaModel().getName(getElement());
}

private String getExtendsString() {
   Collection superclasses = getMetaModel().getAllSuperclasses(getElement());
   if  (superclasses.isEmpty())
      return "";
   StringBuffer sb = new StringBuffer(" extends ");
   for (Iterator i=superclasses.iterator(); i.hasNext();) {
      sb.append(getMetaModel().getName((MBase)i.next()));
      if (i.hasNext())
         sb.append(", ");
   }
   return sb.toString();
}

public String getPrefix(char pSeparator, MBase m) {
   return  "com"+pSeparator+"innoq"+pSeparator+"tutorial_1"+pSeparator;
}
%>
package <%=getPath()%>;
   <iqgen:import prefix="<%=getPrefix()%>" collectiontype="java.util.List"/>
   /**
    * Interface  <%=getClassname()%>
    */
   public interface <%=getClassname()%><%=getExtendsString()%> {
      [...]
   }                        

public String getFilename() {
   return getDirectory() + File.separator
      + getPath(File.separatorChar,
      getElement())
      + File.separator + getName()
      + "." + getFileExtension();
}
	    

public String getPath(char pSeparator, MBase m) {
   return getPrefix(pSeparator, m)
      + getMetaModel.getNamespaceName(m, pSeparator)
      + getPostfix(pSeparator, m);
}
                        

<iqgen:import prefix="<%=getPrefix()%>"
   collectiontype="java.util.List"/>

<%@ page import="ru.novosoft.uml.MBase,java.util.Collection,java.util.Iterator"
         extends="com.innoq.generator.jsp.JspBase" %>
<%@ taglib uri="iqgen" prefix="iqgen" %>
[...]
/**
 * Interface <%=getClassname()%>
 */
public interface <%=getClassname()%><%=getExtendsString()%> {
<iqgen:foreach group="<%=getMetaModel().getOperations(getElement())%>" item="method">
   <%
      String methodName = getMetaModel().getName(method);
      Object retType = getMetaModel().getReturnType(method);
      String retTypeName = getMetaModel().getReturnTypeName(method);
      String parList = getMetaModel().getParameterListAsString(method);
   %>
   /**
    * Method <%=methodName%>
    * <iqgen:foreach group="<%=getMetaModel().getParameterList(method)%>" item="parameter">
    * @param <%=getMetaModel().getName(parameter)%> <%=getMetaModel().getDocumentation(parameter)%></iqgen:foreach>
   <iqgen:if expr="<%=retType!=null%>">
    * @return <%=retTypeName%>
   </iqgen:if>
    */
   public <%=retTypeName%> <%=methodName%>(<%=parList%>) <%=getMetaModel().getExceptionListAsString(method)%>;
</iqgen:foreach>
}                        

<iqgen:foreach group="<%=getMetaModel().getOperations(getElement())%>"
   item="method">
[...]
</iqgen:foreach>                        

Generated code usually isn't perfect. Not all information is contained in model and templates, some needs to be added manually. With simple code generators the manual changes are lost during re-generation. iQgen solves this problem with usercode blocks.

During each generation the output directory is checked for files from earlier runs. If these files exist, the contents of protected sections of these files are inserted into the newly generated files. These special sections are marked as usercode blocks. Here is an example for adding custom imports to a Java file:

[...]
<%@ taglib uri="iqgen" prefix="iqgen" %>
<iqgen:usercode id="imports">
// your own imports
</iqgen:usercode>
<iqgen:import prefix="<%=getPrefix()%>"
   collectiontype="java.util.Collection"/>
[...]                    

To use the usercode tag you have to register the iqgen taglib. Once this is done, you may mark a section of the template with the tag. Make sure that you specify a unique id attribute in the opening tag. This ensures that the right piece of code is merged into this section.

In the generated code the section will look like this:

[...]
//==> Begin Protected Area imports
// your own imports
//==> End Protected Area imports
[...]                    

Never modify the //==> [...] Protected Area [...] lines!

Alternatively to the id attribute you can also set a model element as attribute element:

[...]
<%@ taglib uri="iqgen" prefix="iqgen" %>
<iqgen:usercode element="<%=getElement()%>">
// your own code for the current modelelement
</iqgen:usercode>
[...]

Tag Libraries enable you to write simpler templates. Basically they allow you to move complicated logic from your templates into custom tags. Templates often are much easier to read, understand, and maintain, when Tag Libraries are used. They can be structured more clearly. As a consequence, you should use Tag Libraries whenever you feel that your templates are getting too complicated and unreadable.

Basically you can deploy every JSP 1.1 Tag Library into iQgen. The library has to meet certain criteria, though: First of all, the Tag Library has to be packed into a jar file and this jar file must contain a Tag Library Descriptor (TLD). The TLD is a file that describes the tags contained in the Tag Library. It is best - but not required - to be placed in the META-INF directory for compatibility with some IDEs e.g. IntelliJ IDEA™. The JSP engine uses this file to get all the necessary information to process the Tag Library.

Now the Tag Library can be deployed. You have to copy it into a subdirectory taglibs in the home directory of your iQgen installation (e.g. C:\Programme\iQgen). If the directory does not exist, you have to create it. Now this Tag Library can be used in all iQgen templates.

If the deployed Tag Library uses any libraries (jar files), they have to be put into a subdirectory of the taglibs directory called lib.

In case you want to use the Ant interface of iQgen a special issue arises. The jar file of the Tag Library then has to be placed in a taglibs directory in the lib directory of your Ant installation. The reason for this is that iQgen searches the jars of Tag Libraries relatively to the iQgen jar file. This jar file - in the Ant mode - resides in the lib directory of Ant.

If you have completed all the steps explained in the previous paragraph, you can use your Tag Libraries in your templates. Here is some example code which shows you how to access a Tag Library:

[...]
<%@taglib uri="your_taglib" prefix="your_prefix" %>
[...]
<your_prefix:your_tag  your_attr1="a" your_attr2="b">
   In case of a body tag there can be something in here
</your_prefix:your_tag>
[...]                    

The iQgen Sample Tag Library is included in the iQgen distribution, you can find it in the directory samples/getting_started/taglib_tutorial in your iQgen directory.

The Java class com.innoq.generator.samples.taglibs.SampleTag implements the date and time formating feature. The following TLD is used:

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE taglib PUBLIC "-//Sun Microsystems, Inc.//DTD JSP Tag Library 1.1//EN"  "http://java.sun.com/j2ee/dtds/web-jsptaglibrary_1_1.dtd">
<taglib>
   <tlibversion>1.0</tlibversion>
   <jspversion>1.1</jspversion>
   <shortname>iqgen-taglib-sample</shortname>
   <info>Sample which shows you how to use the taglibs</info>
   <tag>
      <name>date</name>
      <tagclass>com.innoq.generator.samples.taglibs.SampleTag</tagclass>
      <info>Formats Dates</info>
      <attribute>
         <name>time</name>
         <required>false</required>
         <rtexprvalue>true</rtexprvalue>
      </attribute>
      <attribute>
         <name>date</name>
         <required>false</required>
         <rtexprvalue>true</rtexprvalue>
      </attribute>
      <attribute>
         <name>format</name>
         <required>false</required>
      </attribute>
   </tag>
</taglib>

The tutorial includes an Ant build file ( build.xml), which can be used to compile, assemble and install the Tag Library. Just have to call the target install, respectively install-for-ant in order to make this Tag Library available for the GUI or the Ant interface of iQgen.

The important parts of the build file to illustrate what is done to deploy the Tag Library are:

[...]
<target name="dist" depends="compile">
   <copy file="${basedir}/taglib.tld" todir="${classes.dir}/META-INF"/>
   <jar jarfile="${jar.file}" basedir="${classes.dir}"/>
</target>

<target name="install" depends="dist">
   <mkdir dir="${generator.dir}/taglibs"/>
   <copy file="${jar.file}" todir="${generator.dir}/taglibs"/>
</target>

<target name="install-for-ant" depends="dist">
   <mkdir dir="${ant.home}/lib/taglibs"/>
   <copy file="${jar.file}" todir="${ant.home}/lib/taglibs"/>
</target>
[...]

After having successfully installed the Tag Library there will be a taglibsample.jar in the taglibs directory of your iQgen installation. Now you can use the taglibsample Tag Library in your templates:

[...]
<%@taglib uri="taglibsample" prefix="datelib" %>
[...]
<datelib:date format="date"/>
<datelib:date time="<%=System.currentTimeMillis() + 3600000%>" format="datetime"/>
[...]                    

This will result in the following output:

09.08.2002 09.08.2002 11:06:43

To use Transformation Properties from the GUI just create a properties file and place it into the project directory of the transformation you want to use. When the transformation is opened this file will appear in the Transformation Properties combo box in the GUI. Just select it and the properties are available in the templates.

In order to use Transformation Properties on the command line set the -transformationProperties option.

Example:

iqgen.bat "-transform=tutorial_1 -nobackup -transformationProperties=transformation.properties"

In Ant use the transformationProperties attribute of the Generate Task.

If Transformation Properties are set they will be loaded when generation has started. They can be accessed in the templates via methods of the iQgen JSP base class, i.e. any iQgen JSP.

It is also possible to add new properties to the Transformation Properties or to change the value of an existing property. The following methods can be used:

The following example is a set of templates which generate an HTML report for a model. A Transformation Property (sort) is used to decide whether the lists of classes, attributes or methods will be sorted:

[...]
<TABLE cellpadding="3" cellspacing="3" border="1">
   <TR bgcolor="#98AEB7" align="center">
      <TD>Class Name</TD>
   </TR>
<% List list = new ArrayList(getAttributeList("CLASS_KEY")); %>
<iqgen:if expr="<%=\"true\".equals(getProperty(\"sort\"))%>">
   <% Collections.sort(list, myComparatorInstance); %>
</iqgen:if>
<iqgen:foreach group="<%=list%>" item="item" type="ru.novosoft.uml.MBase">
   <TR bgcolor="#FFFFFF" align="right">
      <TD>
         <a href="<%=getMetaModel().getPath(item)%>/<%=getMetaModel().getName(item)%>.html">
            <%=getMetaModel().getName(item)%>
         </a>
      </TD>
   </TR>
</iqgen:foreach>
</TABLE>
[...] 

 sort=true 

The UML profile in this case is very simple. What we want to show is how to use model validation. Model validation answers the question: Does the UML model satisfy the UML profile?

The UML profile looks like this:

First let us start with the invalid model. It looks as follows:

Figure 2.4. Invalid model

You can find the invalid model as XMI file in the folder validation/model. Please open the transformation samples/getting_started/validation/validation.iqp. When you start generation and change to the validation page you should see that the model has three validation errors:

The Unknown stereotype error is a warning, the missing rolename exceptions are errors (different images in table!). If we used a fatal error the execution would have stopped. In our example the validation violation status are arbitrarily.

The next step is that we fix the model, remove the validation violations and re-generate. The correct model looks as follows:

Figure 2.5. Valid model

You can load the model from the XMI file valid_model.xmi. Now re-generating will not produce errors anymore!

You can find both templates main.jsp and report.jsp in the templates directory of this example. Most of the used methods are explained in further examples so we can concentrate on the validation method (see main.jsp):

[...]
private static final List STEREOTYPES = Arrays.asList(
   new String[] {"Entity", "Process", "Enum"}
);
[...]
public boolean canBeGenerated(MBase pElement) {
   return super.canBeGenerated(pElement)
      || getMetaModel().isAssociation(pElement);
}

public ValidationMessage isValid(MBase pElement) {
   String s = getMetaModel().getStereotype(pElement);
   // valid stereotypes
   if (getMetaModel().isClass(pElement) && !STEREOTYPES.contains(s)) {
      return new ValidationMessage(ValidationMessage.WARN, "Unknown stereotype: " + s);
   }
   // navigable associations do have a rolename?
   if (getMetaModel().isAssociation(pElement)) {
      for (Iterator it = ((MAssociation)pElement).getConnections().iterator(); it.hasNext(); ) {
         MAssociationEnd lAssocEnd = (MAssociationEnd)getMetaModel().getOppositeEnd((MBase)it.next());
         if (getMetaModel().isNavigable(lAssocEnd)
               && getMetaModel().getName(lAssocEnd).length() == 0) {
            StringBuffer sb = new StringBuffer();
            sb.append("Association [");
            sb.append(getMetaModel().getTypeName(lAssocEnd.getOppositeEnd()));
            sb.append(" -> ");
            sb.append(getMetaModel().getTypeName(lAssocEnd));
            sb.append("] is navigable but lacks a rolename.");
            return new ValidationMessage(ValidationMessage.ERROR, sb.toString());
         }
      }
   }
   return new ValidationMessage(ValidationMessage.OK, "No error found!");
}
[...]                

The model validation happens programmatically. For validation purpose you can use the hook method isValid. This method is called for every model element that is to be processed during generation. You can control which model element leads to the generation of an artifact by overwriting the method canBeGenerated. By default only classes and interfaces are generated. In our example we have added associations, because the UML profile demands a validation of associations, too. Our intention is to check navigable associations and their rolenames.

In our custom isValid method we check whether all classes have a valid stereotype - if not we return a ValidationMessage of type ValidationMessage.WARN. Then we check whether all navigable associations have rolenames.

To do this we check, if the element is an association, then we take a look at the association's ends. Every association consists of two association ends which you can get by calling the method getConnections. Finally we check the UML profile constraint ("Association is navigable and has a rolename?!?"). If this constraint is violated we return a ValidationMessage of type ValidationMessage.ERROR.

If the element is no association in the first place, there is nothing to test form, so we simply return a ValidationMessage of type ValidationMessage.OK.

The UML profile looks like this:

The model describes a simple message board. The interface to the message board is the board itself. You are able to login, logout, add a message (addMessage) and add a reply to a message (addReply). Entities are User and Message. Every Message can have multiple replies which are also messages. In addition it is possible to add an Attachment to every Message.

Figure 2.6. Simple message board model

First of all: If you try to verify the generated IDL file you have to download an IDL compiler. The JDK IDL compiler idlj.exe does not support forward declarations, which are required for this example.

In structs we have to list all attributes and navigable associations. For this purpose we write a helper class AttributeList. Its init method iterates over all attributes and associations. For an attribute and an association with multiplicity one an Attribute will be created and for an association with multiplicity many a Sequence will be created. In order to take advantage of the dynamic reloading feature for the helper class, we place it in the classes directory.

Finally we are able to iterate over the resulting collection in idl.jsp:

[...]
struct <%=getMetaModel().getName(_struct)%> {
<iqgen:foreach group="<%=new AttributeList(getMetaModel(),_struct).getElements()%>" item="_attribute" 
                    type="com.innoq.iqgen.classloading.Attribute">
   <%=getProperty(_attribute.getTypeName(),_attribute.getTypeName())%> <%=_attribute.getName()%>;
</iqgen:foreach>
}; // <%=getMetaModel().getName(_struct)%>
[...]                    

Open the project file /samples/getting_started/classloading/classloading.iqp and load the model. Set the Properties/Dirs/User Classes to C:\iqgen\samples\getting_started\classloading\classes (or where else your sample is located!). Press the Generate button.

A single file should have been generated. Try to make an IDL compilation of this file (maybe use JacORB ). It will lead to the following exception:

$ ./idl.bat Classloading.idl
Error in Classloading.idl, line:42(13): Declarator attachment already defined in scope.
 Attachment
Can't recover from previous error(s), giving up.
 : parse error: null                    

The problem is that the type Attachment is equal to the attribute name attachment!

How do we solve this problem?

We can change the getName method in com.innoq.iqgen.classloading.Attribute to:

public class Attribute {
[...]
   public String getName() {
      //old : return metamodel.getName(clazz);
      return "m" + StringHelper.fu(metamodel.getName(clazz));
   }
[...]
}                    

Just recompile the Attribute class and regenerate the model - now the IDL compilation should work just fine!

The UML profile looks like this:

The model describes a login screenflow:

Figure 2.7. Login flow

The first step to take when introducing a generative approach is to embed the code generation process into your processing chain. In general, this means that you should generate code from within your build scripts. The iQgen Ant integration allows you to call iQgen from within your Ant scripts. If you prefer make or some other build management tool, you can use the command line tools.

As with other software artifacts, you should take care to put your source model under configuration management control. Depending on your CASE tool of choice, you can either version the model file itself or only the XMI export. While the first choice is preferable, some tools don't offer this possibility - most notably those that are based on some centralized repository. They do, however, usually offer some built-in versioning mechanism instead.

As a result, your build cycle will roughly resemble the following process:

It is a recommended best practice to set up a periodic, automated build process that runs centrally to minimize integration problems. When using a generative development process, you should make sure that your centralized build includes the code generation step. This is the best way to make sure that no code that has been manually added outside the protected areas becomes part of the system.

In the figure below you can see the screen of the sample transformation Tutorial_1. A transformation is defined as a set of configuration items as displayed in the initial screen above. The main items of a transformation (the so called configuration set) are:

As soon as the source model is selected, the generator loads the XMI file. The model contents are displayed in the pane Model Elements.

Figure 4.1. Main window with loaded objects

You do not need to generate the whole model every time. Instead you can select single or multiple model elements which you want to generate.

The Generate button will be enabled, if all settings are made and a model is loaded. You can load the model by selecting Run Load Model or by clicking the corresponding toolbar button. This button will be enabled, if the source model file is an existing and valid XMI file. The GUI will mark invalid entries with a red border:

Figure 4.2. Invalid entry (directory does not exist)

Figure 4.3. Valid entry (existing directory)

The root path helps you to move projects to another location. You can physically save your project under a different directory. When changing the root path, iQgen offers to translate the other transformation settings (e.g. source model file) to this new location.

The following tables provide a reference for GUI menu options.

To set iQgen properties, open the properties dialog with the menu item Options Properties or simply with the accelerator Ctrl-P. There are various kinds of settings. Most settings are self-explanatory.

JSP Engine

If you like to use more than one instance of iQgen at the same time you will have to define different a ports for each instance. You can set the port to a static number (e.g. 16222), a range (e.g. 16222-16333) or a list of free port numbers (e.g. 16222;16333;16444)

Figure 4.4. JSP-Engine properties

To set the log level please press . The table below shows which log levels are available.

Figure 4.5. iQgen project editor

Double-click a file with the .iqp extension to open the iQgen project editor. The editor shows several pages to edit the project file.

You can start generation by clicking the button in the toolbar or by opening the popup menu on a .iqp file and selecting iQgen Generate.

The iQgen console is released as a view, and you can open it via Window > Show Views > Other > iQgen Console. The following figure shows a list of generated files and some other information of the generation status.

Figure 4.6. iQgen console

You can set the logging filter and open a detail view by double-clicking an element of the list. If the element is a generated file, the file will be opened in the corresponding editor (e.g. Java files). If an error occurred while generating, you can double-click the error entry in the iQgen console (red triangle) and the JSP editor is opened with the right JSP file at the line which produced the error.

A short list of features we are thinking about:

The IfTag enables you to generate code depending on conditions. The body of the tag will only be executed if the condition (stored in the tag attribute expr) is true. Syntax:

<iqgen:if expr="[true|false]">
...body
</iqgen:if>                    

Examples:

<iqgen:if expr="true">
...something to write
</iqgen:if>                    

<iqgen:if expr="<%=!attrName.equals(\"name\")%>">
...something to write
</iqgen:if>                    

<iqgen:if expr="<%=isProcessable(element)%%>">
...something to write
</iqgen:if>                    

The ForEachTag is used to iterate over a Collection, a List or with an Iterator.

<iqgen:foreach group="<%=attr.iterator()%>" item="element" type="ru.novosoft.uml.MBase">                    

String attrName = getMetaModel().getName(element);

The ImportTag is only useful if you are generating Java source code. This tag creates the necessary import statements, which usually is a pretty hard job. This encapsulation dramatically simplifies the development of templates that generate Java code.

<iqgen:import prefix="<%=getPrefix()%>" collectiontype="java.util.Collection"/>
<iqgen:usercode id="imports">
// ... own imports
</iqgen:usercode>                    

The parameter prefix is set to the path of the class. This is helpful for evaluating import statements because none of the classes in this path needs to be imported. The collectiontype parameter defines which collectiontype should be used for *-associations.

The PropertyTag is only useful in the context of Java, too. It encapsulates a list of attributes by generating getter and setter methods (see samples/getting_started/tutorial_1/templates/attribute.jsp):

<iqgen:properties>

Developers need to be able to extend generated code. To ensure this, iQgen recognizes protected areas which remain unchanged during re-generation. In the generated source code a protected area may look like this:

//==> Begin Protected Area global
// ...
//==> End Protected Area global                    

Developers have to write their code in these areas. During a re-generation iQgen merges generated and implemented areas.

In a template the protected area is marked with the usercode tag like this:

<iqgen:usercode id="global">
// ...
</iqgen:usercode>                    

The id (here global) is used to identify a protected area within the generated code. The name for the id has to be unique.

This tag writes the name of the template in your generated code.

Generated from: <iqgen:jspfilename/>
        

We start with a simple UML model and redraw it in every modeling tool we test. You can find the model for the test at the beginning of each section. After exporting the model to XMI format, we try to access all of the model information we have specified. In some cases we are able to retrieve all information, in some cases we are not.

Since version 2.0 we support both:

The mentioned categories in the following tables can be found in the model of each chapter.