На этом шаге рассмотрим прямое и обратное проектирование в UML.

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

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

    И все же разрабатываемые вами модели чаще преобразуются в код. UML не регламентирует никакого конкретного отображения на конкретный объектно-ориентированный язык программирования,это касается диаграмм классов, содержимое которых ясно отображается на все распространенные объектно-ориентированные языки программирования, в частности Java, C++, Smalltalk, Eiffel, Ada, ObjectPascal и Forte. Кроме того, UML предусматривает отображение на коммерческие объектные языки, такие как Visual Basic.

    Прямое проектирование (forward engineering) – это процесс трансформации модели в код посредством отображения на язык реализации. В результате прямого проектирования происходит потеря информации, поскольку модели, описанные на UML, семантически богаче, чем любой современный объектно-ориентированный язык программирования. Фактически это главная причина существования моделей наряду с кодом. Структурные средства, например кооперации, и поведенческие, например взаимодействия, могут быть ясно визуализированы с помощью UML, но не так ясно – в исходном коде.

    Чтобы осуществить прямое проектирование диаграммы классов, необходимо:

1. Идентифицировать конкретные правила отображения классов в код для выбранного вами языка (или языков) реализации. Эти правила будут касаться проекта в целом либо всей вашей организации.
2. Если требуется, в зависимости от семантики выбранных языков установить ограничения на некоторые средства UML. Например, UML позволяет моделировать множественное наследование, а Smalltalk допускает только одиночное. Вы можете либо запретить разработчикам моделировать множественное наследование (что делает вашу модель зависимой от языка), либо разработать идиому, которая трансформирует эти богатые средства в язык реализации (что несколько усложняет отображение).
3. Использовать помеченные значения для указания параметров реализации на вашем целевом языке программирования. Вы можете делать это на уровне индивидуальных классов, если нужен тонкий контроль, или же на более высоком уровне (например, на уровне коопераций или пакетов).
4. Использовать инструменты для генерации кода.

    На рис. 1 вы видите простую диаграмму классов, представляющую реализацию образца цепочки обязанностей (responsibility pattern). Эта конкретная реализация включает три класса: Client (Клиент), EventHandler (ОбработчикСобытий) и GUIEventHandler (ОбработчикСобытийGUI).

Рис.1. Прямое проектирование

    Классы Client и EventHandler – абстрактные, GUIEventHandler – конкретный. К EventHandler относится обычная операция, предусмотренная этим образцом, – handleRequest (обработатьЗапрос), хотя к его реализации добавлено два закрытых атрибута.

    Все эти классы предполагают отображение на язык Java, как отмечено в их стереотипе. Прямое проектирование классов данной диаграммы на Java достаточно просто при использовании инструментальных средств. Прямое проектирование класса EventHandler на Java генерирует следующий код:

public abstract class EventHandler {
  EventHandler successor;
  private Integer currentEventID;
  private String source;

  EventHandler() {}
  public void handleRequest() {}
}

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

    Чтобы осуществить обратное проектирование диаграммы классов, необходимо:

1. Идентифицировать правила отображения для выбранного языка или языков реализации – это вам понадобится сделать для всего проекта или всей организации.
2. Используя какое-либо инструментальное средство, указать код, который нужно подвергнуть обратному проектированию. Применяйте инструмент для генерирования новой модели или модификации существующей, в отношении которой ранее применялось прямое проектирование. Не стоит ожидать, что обратное проектирование породит единственную компактную модель на основе большого фрагмента кода. Вам придется выбирать небольшие фрагменты кода и строить из них модель.
3. Просматривая модель, создать диаграмму классов с помощью какого-либо инструментального средства. Например, вы можете начать с одного или нескольких классов, а затем расширять диаграмму, прорабатывая конкретные связи или включая соседние классы. Показывайте или скрывайте детали диаграммы в соответствии с вашими намерениями.
4. Вручную добавить к модели информацию о проектировании, чтобы показать те аспекты дизайна, которые пропущены или скрыты в исходном коде.

    Создавая диаграммы классов на UML, помните, что каждая из них – это лишь графическое изображение статического представления дизайна системы. Ни одна диаграмма классов не обязана включать все, что касается представления дизайна системы. Однако диаграммы классов в совокупности сообщают пользователю полную информацию, необходимую для статического представления системы; хотя каждая из них представляет только один ее аспект.

    Хорошо структурированная диаграмма классов: