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:
Rhapsody uses GUID-strings to designate its UML-Model-elements. The advantage is: Changing of names of model elements don't change its coherence.
The XMI-Model is created new anytime if it is called. Rhapsody should thought, there are new model elements. It doesn't recognize
the replacement of existing elements. Therefore new GUID-idents are created. That is done in the ZBNF_XMI.rpy-Model.
After creation the new model elements from import XMI, there are saved, and the other ZMAKE.rpy-Project should be opened. There an add-to-model-operation should be done. This operation accepts, that adequate (same name in package) model elements are replaced by the
new imported content. Thereby the existing GUID-numbers are used, respectively the imported elements replaces the exiting
elements which same names at the same package positions. With this tricky operation the consitence of the imported XMI-content
with other existing classes or diagrams is realized. There is also a possibility to support renaming in the Java-sources:
You should done the renaming or package change of classes in this Rhapsody-projekt too, after them import it.
Work for future:
Give feedback if newer XMI-version are supported, instead XSL-scripts Java and JZcmd text preparation should be used for a new XMI version.
Give feedback if other UML-tools are tested with the XMI.