Enterprise Architect Генерация кода Java-кода Импорт файла

Question

Я пытаюсь сгенерировать Java-код из диаграммы классов EA UML. Я определяю два класса, и у них есть корабль отношения композиции.

говорят, класс А содержит список класса B.

Я могу установить класс сбора по умолчанию в список в диалоговом окне генерации кода и правильно генерирует код, как:

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

Но я не могу автоматически генерировать оператор импорта. как показано ниже:

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

Я знаю, что есть раздел в диалоговом окне генерации кода, где я могу указать полный оператор импорта, но у меня есть много классов, и я хотел бы EA автоматически генерировать операторы импорта.

Я также играл с шаблонами кода, но я не мог заставить его импортировать в шаблоны кода ничего, кроме жестко закодированных операторов импорта.

макросы

importPackagePath 
importClassName 

кажутся пустыми.

Может ли кто-нибудь помочь мне изменить шаблон кода, чтобы выяснить, какие импорты должны быть сделаны?

Спасибо,

С уважением,

Vimal

Answer 1

Я думаю, вы должны держаться подальше от шаблонов генерации кода. Проблема здесь в том, что обработка классов сбора выходит за рамки обычного генерации кода. Если у класса есть член, тип которого является классом в другом пакете, EA генерирует правильные операторы импорта - но только если классы присутствуют в модели, а классы коллекционирования - нет.

Есть три способа обойти это:

1) Принимают, что сгенерированный код сломан.

Сгенерируйте код, затем откройте его в среде IDE (NetBeans, Eclipse или что-то еще, что вы используете) и позвольте ему получить обоснованное предположение о добавлении правильных операторов импорта.

Это быстро и легко, но вам нужно будет проверить результаты. Существует также риск: если ваш класс «В» импортирует пакет, который содержит класс «Список», компилятор не будет жаловаться, но ссылочный класс «Список» не является тем из них, который является java.util, что означает, не получая код, который, как вы думали, вы делали.

2) Модель классов коллекций.

Создайте пакет «java» с дочерним «util» и классом шаблона «Список», а затем измените модель так, чтобы вместо отношения 0 .. * к B, A имеет отношение «1» к этот тип «Список» (не B), но создается экземпляр типа B. Правильная связь для этого была бы привязкой к шаблону.

На пути моделирования классов коллекции необходимо импортировать rt.jar в ваш проект. Это занимает некоторое время, хотя, и убедитесь, что вы отключите автоматическое создание диаграммы или у вас может закончиться нехватка памяти. Но вы будете иметь все классы утилиты, импортированные раз и навсегда.

Если вы хотите быть в безопасности, удалите классы коллекции из вариантов Java (Tools - Options - Source Code Engineering - Java), поэтому EA не пытается их использовать. Но если вы измените все отношения, EA не будет использовать сконфигурированные классы коллекций.

Это приводит к наиболее правильной модели, а также решает проблему того, как обращаться к другим классам полезности (например, к календарю), но может быть очень много работы, если у вас есть большая модель без классов коллекции.

3) Используйте полные имена для классов коллекции.

В вариантах Java вместо List<#TYPE#> введите java.util.List<#TYPE#>. Компилятор Java не нуждается в операторах импорта, если типы ссылаются на их полностью квалифицированные имена.

Это очень быстро и просто, а сгенерированный код является правильным. Недостатком является то, что код становится немного громоздким.

Если вам нужны только классы коллекции для работы, я бы пошел с этим. Если вы хотите обратиться к другим общим классам утилиты, я бы сказал, импортировать rt.jar и переработать модель.