==XmlDocuGeneration==
@ident=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:

[[Image:Img/Overview_omdZBNF.png]]

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.
