readme - Java2XMI

readme - Java2XMI

Inhalt


Topic:.readme_Java2XMI.

What is Java2XMI

The ZBNF-Script in zbnfjax:zbnf/Java2C.zbnf was created and is used in the Java2C-Project. There Java-Sourcecode is parsed using ZBNF and converted with Algorithm written in Java to C-Language-programs.

The same script is used to parse Java-code to generate XMI-Code. The XSL-Scripts to generate the XMI are located in zbnfjax:xsl/Java2xmiTypes.xsl and zbnfjax:xsl/Java2xmi.xslp. Using this scripts it is able to convert normal Java-Sourcecodes to an XMI-Model for UML. Yet only the version XMI 1.3 is supported. This is an older version but works with some tools. Support of newer versions of XMI will be done in future.

Look at this graphic:


This UML-class diagramm shows the class associations within the ZBNF-parser. This class diagramm is created using the XMI-File of this example, imported in the Rhapsody-UML-Tool. The XMI images the repository of the UML-model, the creation of this class diagramm uses the model informations of the XMI-file. No additional informations are stored there, only the informations produced with the Java2XMI-converter. The graphic positions are tuned manually. But it needs only about one hour to get this diagramm. The time to spend is used to position the classes, correct layout of the dependency-lines, choose the attributes and methods to show in the class body (only the most important) and so on. It is a work of documentation. The base data to do this work is the repository got from the XMI-import.

Viewing the graphic unoptimal associations etc may be detected, which should correct in the source code. It is a recursion of documentation and source writing. This class-diagramm may be optimal, because the software is optimal.

Association to container:

The XMI converter detects an Java-field like

List<Type> myList;

It is not an association to a List, the java.util.List is only the container mediator. It is an association to the Type with multiplicator *.

The same is done for LinkedList, ArrayList Map, TreeMap. This feature is programmed in the zbnfjax:xsl/Java2xmiTypes.xsl script.

The example contains:

The sources in srcJava_Zbnf contains a JZcmd-script-file:

ZBNF/srcJava_Zbnf/_make/genXMI_Zbnf.bat

Follow this link and view and invoke this file. It generates an XMI-File in the directory

ZBNF/Rhapsody_UML/srcJava_Zbnf.xmi

That directory contains some files for a Rhapsody UML-Model which are used to build the graphic above.

The XMI-File should be inputted in Rhapsody calling its XMI-input-tool. It should need an extra licence of Rhapsody. Rhapsody is a commercial tool, see its internet page. You can download a evaluation licence to test it. But you can use another tool too. The XMI-File generates XMI-version 1.3, which is supported from Rhapsody currently. It isn't the newest version, because the development of the Java2XMI-scripts are done in the past (2007/2008). Newer versions may be supported in future.

The Rhapsody-Model which is used for import the XMI-File is

ZBNF/Rhapsody_UML/srcJava_Zbnf_XMI.rpy

Before you import the XMI-File, you must delete the maybe existing package GenerateFromJava That package is contained in the XMI file. Rhapsody does only allow import of non-existing (new) model elements via XMI, not update.

The philosophy of working with UML is often: The UML-model is the master of sources, and codes (source line files) are generated from the UML. But because powerful GUIs for source line files are existing, the reverse way may be a good decision instead: The source is the line code, written with powerful GUIs. The UML-Tool is only a tool for control architecture and documentation. For this workflow anytime a new XMI model can be created from the source line files, and the UML-model should be updated with them. The UML-model holds the graphic diagrams.

To update an imported XMI-model in Rhapsody there is a trick: Another Rhapsody project is used for working. The necessity of 2 models are need because the following context:

Work for future: