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

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

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

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

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

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

На рисунке ниже приведена простая диаграмма классов, представляющая реализацию образца проектирования, Цепочка Обязанностей. Об образцах проектирования более подробно мы поговорим во второй части нашего курса. Наша конкретная реализация включает три класса: Client (Клиент), EventHandler (ОбработчикСобытий) и GUIEventHandler (ОбработчикСобытийGUI). Классы 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() {}

}