Введение

Предполагается, что вы знакомы с общей информацией о J2EE как о технологической платформе, изложенной в Концепция: Обзор J2EE (Java 2 Platform Enterprise Edition) и Концепция: Преобразование из Проекта в Код. Некоторые концепции этого руководства принадлежат UML 1.4, несмотря на то что их можно применять в контексте модуля на основе UML 1.3. Если вам трудно в чем-то разобраться, поймите, что две спецификации UML говорят по сути.

Структурирование модели реализации

Задача: Структурирование модели реализации  описывает способ создания структуры Модели реализации, которая строго соответствует структуре Модели проекта, но, в то же время, отражает все ограничения среды разработки, а также поддерживает параллельную разработку и инкрементную интеграцию.

Структура Модели реализации для приложения J2EE зависит от среды разработки и реализации, однако, в общем случае, существуют четыре потенциальные структуры Модели реализации J2EE:

• Поддержка развертывания (модули и файлы описания J2EE)
• Виртуальная структура каталога (JSP, страницы HTML)
• Каталог Java для элементов, развернутых на Web-сервере (сервлеты, объекты JavaBean)
• Каталог Java для элементов, развернутых на сервере приложений EJB (объекты EJB)

Моделирование подсистем реализации

Представление реализации в Рабочий продукт: Документация по архитектуре программного обеспечения предоставляет обзор высокого уровня модели реализации. Сюда включена идентификация Подсистем реализации. В приложении J2EE Подсистемы реализации могут не соответствовать одному каталогу файловой системы или одному пакету модели, потому что Подсистема реализации может включать в себя элементы, отличные от Java, из одной модели (такие как JSP и страницы HTML) и элементы Java из другой. Одна стратегия управления этим состоит в том, чтобы иметь параллельные структуры пакетов в каждой модели. Пакеты с одинаковым именем в каждой модели неявно связаны.

Обычно Подсистема реализации предоставляет реализацию одного развертываемого Файла реализации (JAR, WAR или EAR). В этом случае, идентификация развертываемых файлов может служить идентификации Подсистем реализации.

Представление физических элементов, состоящих из Каталогов реализации и Файлов реализации, может находится в каждой Подсистеме реализации. Могут существовать также логические элементы, состоящие из классов, компонентов, пакетов и так далее, что соответствует элементам Рабочий продукт: Модель проекта, но является точной моделью исходного кода (модель проектирования полного обхода). В разделе Концепция: Преобразование из Проекта в Код находится более подробная информация о взаимосвязи между Моделью проекта и Моделью реализации.

Модели проектирования полного обхода предоставляют точное представление исходного кода. В J2EE каждый пакет модели Java представляет пакет Java, каждый класс представляет класс Java, и так далее. Однако, часто возникает потребность поддержки моделей проектирования полного обхода с дополнительной информацией, в том числе:

• диаграммы, которые показывают информацию и не создаются автоматически в процессе проектирования полного обхода
• абстракции модели высокого уровня

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

Моделирование каталогов реализации

Проектирование полного обхода, как правило, управляет только подмножеством каталогов, требуемых в среде разработки. Часто нужны дополнительные каталоги для организации тестовых артефактов, модулей развертывания, документации и так далее. Обычно моделирование не требуется, потому что каталоги могут быть видны как часть файловой системы.

Моделирование файлов реализации

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

Обычно существует один файл .java для каждого интерфейса или класса Java, и один скомпилированный файл .class для каждого файла .java. Таким образом, моделирование этих файлов не очень интересно.

В J2EE подсистема обычно содержит один или несколько файлов архива (JAR, WAR или EAR).

Архивные файлы правильнее всего моделировать как составную взаимосвязь архивного файла и файлов, которые он содержит. Однако, когда скомпилированные файлы .class составляют файл JAR, может оказаться более полезным показать зависимость от файла JAR классов и интерфейсов, которые он в конечном счете реализует.

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

Перекрытие архивных файлов

Возможно, но не рекомендовано, определять два архивных файла, которые содержат некоторые одинаковые элементы. Например, два файла EAR могут содержать некоторые, но не все, одинаковые файлы JAR EJB, или два файла JAR EJB могут содержать одинаковые объекты EJB, но иметь разные файлы описания.

Лучше всего, чтобы архивные файлы не перекрывались, сохраняя точное соответствие между подсистемами реализации и разворачиваемыми архивными файлами. Однако, если перекрытие необходимо, может оказаться полезным смоделировать его вместе с причиной такого перекрытия.