Archiving Enterprise Architect Java Code File

Question

I am trying to generate Java code from an EA UML class diagram. I define two classes, and they have a ship composition relationship.

let's say class A contains a list of classes B.

I can set the default collection class to List in the Code Generation dialog box, and it correctly generates code like:

class B { public List<B> m_B; }; 

But I cannot automatically generate an import statement. as below:

 import java.util.List; class B { public List<B> m_B; }; 

I know that there is a section in the Code Generation dialog box in which I can specify the full import statement, but I have many classes, and I would like EA to automatically generate import instructions.

I also used code templates, but I could not get it to import anything into the code templates except hard-coded import statements.

macros

 importPackagePath importClassName 

seems empty.

Can someone help me modify the code template to find out what import operations I need to perform?

Thanks,

Hi,

Vimal

Answer 1

I think you should avoid code generation patterns. The problem here is that handling collection classes goes beyond the usual code generation. If a class has a member whose type is a class in another package, EA generates the correct import statements, but only if the classes are present in the model and the collectible classes are not.

There are three ways around this:

1) Accept that the generated code is broken.

Generate the code, then open it in the IDE (NetBeans, Eclipse, or whatever else you are using) and let it accept the reasonable assumption of adding the right import statements.

It's quick and easy, but you need to check the results. There is also a risk: if your class “B” imports a package that contains the class “List”, the compiler will not complain, but the reference class “List” is not the one that is java.util, which means without getting the code, which you thought you did.

2) Model collection classes.

Create a “java” package with a child “util” and a class “List”, and then change the model so that instead of the relation 0 .. * to BA has a relation “1” to this “List” (not B), but an instance of type B. The correct ratio for this would be a template binding.

During the modeling process, collection classes should import rt.jar into your project. This takes some time though, and make sure you turn off automatic charting or you may run out of memory. But you will have all utility classes imported once and for all.

If you want to be safe, remove the collection classes from the Java options (Tools - Options - Source Code Engineering - Java), so EA does not try to use them. But if you change all relationships, EA will not use the configured collection classes.

This leads to the most correct model, and also solves the problem of how to access other utility classes (like a calendar), but it can be a lot of work if you have a large model without collection classes.

3) Use full names for collection classes.

In the Java parameters, instead of List<#TYPE#> enter java.util.List<#TYPE#> . The Java compiler does not need import statements if the types reference their fully qualified names.

It is very fast and simple, and the generated code is correct. The downside is that the code gets a little cumbersome.

If you only need collection classes to work, I would go with that. If you want to refer to other general utility classes, I would say import rt.jar and rework the model.