2.1 Project properties
To make work in DbUML more organized, the application uses projects. A project is a group of properties defining location of UML model information, template used for generation, database used for data mapping, etc..
The must to be specified property is a UML model location.??????? The application can load class models from different sources -
- XML (XMI) file. The standard way to share UML information. Most UML tools support export into XMI file. The XMI standard has several versions - 1.0, 1.1 and 2.0 are supported).
- IDL file. IDL specification is used to describe classes and interfaces using simple, C-like syntax. Some UML tools have an option to export class model into an IDL file.
- Enterprise Architect COM server connectivity. Enterprise Architect is a popular UML tool from Sparx Systems Ltd. You can load class model directly from a currently running application. Unfortunately, Enterprise Architect has a very slow performance of COM interface - the issue is still not resolved at least in version 7.5. This way of model loading was implemented with hopes for future improvement of otherwise a very nice and relatively inexpensive application.
- Enterprise Architect repository. The recommended way to work with Enterprise Architect in a multi-user environment is to use a database repository. DbUML can load the model directly from the repository. So far, this is the fastest and mostconvenient way to work with Enterprise Architect.
To execute the general purpose of the application - source code generation - we have to configure the second critical DbUML project property - generator information. DbUML works with templates defined using TEAL language and compiled as dynamic libraries. So, we have to specify what DLL file has to be used as a template. One DLL file can contain several templates. By default, the template with name "main" is used. But you can also explicitly specify the template name. In such a way, you can keep related templates in a single file.
Optional, but in most cases the vital part of a project is a database mapping configuration. If no database mapping is required for source code generation, live this section empty. Otherwise you have to make a decision where to keep mapping information (mapping repository) –
The repository is not the only part of configuration required for mapping. You have to provide connection information for database structure you want to map to the class model. Again, there are two options – ODBC connection and native Oracle connection. The connection strings follow the same “user name”/”password”@”database name” format. If you specify both Oracle and ODBC connection – two mapping panels will be shown – first for Oracle database and the second one for database accessible through ODBC interface.
2.2 Text generation
Now, when the UML model location and template are specified, the actual source code generation can be done.
In the UML model, all classes are grouped by packages. It simplifies the model management, usually a single package contains logically related classes. Using the DbUML application, you can explore the hierarchy of the UML packages and classes. DbUML shows the package tree and allows to check the class structures. DbUML allows to generate the source code for a single class or for a whole package. A batch generation is also possible. In batch generation, dialog several packages or classes can be selected and generator will produce a source code for each of them.
You have to realize, TEAL generators, used in DbUML, generate texts, not files. It is the responsibility of the DbUML application with the help of the user to save the generated text as files. The file saving can be simplified and even automatized using special file management directive $$$FileName recognized by DbUML. If an expression like "$$$FileName=myfile.txt" is included in a generated text, the text will be saved in a file named "myfile.txt". The directive will be also excluded from the text. If the generated text contains several $$$FileName directives each one will force saving of its own portion of the text into the named file. The text portion controlled by directive starts on the next line after directive and ends before next directive of end of file. Using multiple $$$FileName directives you can easily generate several related files constructed for the same package or class, for example header and implementation files in C/C++.
If generation happens in batch mode, DbUML automatically saves files using names specified by $$$FileName directive. If generation is done for a single package or class, the user has to save the result manually - the specified file name will be used as the default one.
One big problem arises when the model has to be modified after the source code has been already generated. If generated source code has been manually modified, all such modifications will be overridden by the next re-generation process. Such a scenario is very typical for most project developments, so DbUML offers the possibility to merge generated text with a previously generated one. DbUML uses special markers to identify text lines that cannot be overridden. The template designed has to identify all possible places where manual modifications can be allowed and place markers there. Two markers are used to identify the beginning and ending of a non-overridible (custom) block. When DbUML saves a file, it collects all non-empty custom blocks from the old version of the file and inserts them in appropriate places in the newly generated file. To identify correct locations, DbUML relies on the uniqueness of custom block names. It is also the responsibility of the template designer to generate custom blocks with unique names.