Интервью с Полом Кузаном

Наталия Елманова: Современный российский рынок средств моделирования — это главным образом рынок инструментов IBM/Rational и Computer Associates. Чем, помимо невысокой цены, семейство продуктов Together лучше Rational Rose или CA AllFusion Modelling Suite?

Пол Кузан: Во-первых, рынок Rational и CA всегда был рынком, ориентированным на бизнес-аналитиков, а их инструменты изначально являлись инструментами чистого UML-моделирования, тогда как продукция Together предназначалась для разработчиков. Правда, сейчас компания Borland старается удовлетворить потребности участников всех этапов жизненного цикла приложений, поэтому мы создали редакцию Together Designer, предназначенную для бизнес-анализа и определения требований.

Во-вторых, наши продукты обладают средствами интеграции с другими инструментами поддержки жизненного цикла приложений.

К тому же потребности бизнес-аналитика и потребности разработчика сильно различаются. Бизнес-аналитик нуждается в инструменте, который работает с UML-моделями и обладает средствами интеграции с инструментами управления требованиями и инструментами управления проектами, а разработчику нужен инструмент UML-моделирования, обладающий средствами визуализации его кода, чтобы достичь высокого качества кода и сгенерировать документацию. Поэтому у нашего продукта существуют разные редакции: Together Designer — для бизнес-аналитиков, Together Developer — для разработчиков. Однако формат файлов и репозитарий моделей для аналитиков и разработчиков основаны на одной и той же XML-схеме и одинаковы для всех редакций Together.

И последнее отличие наших продуктов от конкурентов — это технология LiveSource, изобретенная в TogetherSoft и позволяющая поддерживать UML-диаграмму классов и код приложения в состоянии синхронности.

Н.Е.: Rational Rose и Rational XDE тоже позволяют генерировать код на основе модели и осуществлять обратное проектирование. В чем заключается отличие генерации кода в Together от генерации кода с помощью этих продуктов?

П.К.: Если вы создаете класс в Rational Rose, его нужно сохранить в промежуточном хранилище, и только потом можно генерировать код. Rational XDE действительно позволяет осуществлять прямое и обратное проектирование и реализует эти операции достаточно быстро, но опять же через промежуточный MDX-файл.

В Together же нет концепции промежуточного хранилища — классы хранятся в самом коде и диаграммы классов унаследованы непосредственно от исходного кода на языках Java, C ++, Visual Basic .NET, CORBA IDL или C#. Единственный источник для диаграммы классов — это код, а для хранения сведений о положении элементов модели на экране и их размерах существует отдельный XML-файл. И если мы внесем изменения в саму модель, например добавив атрибуты к классу, эти изменения немедленно произойдут и в коде. Именно в этом и заключается технология Live Source. Отмечу, что мы не помещаем в код никаких маркеров, связанных с моделированием, которые могли бы помочь в синхронизации кода и модели.

Н.Е.: Какова цель выпуска бесплатной версии Together Designer Community Edition?

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

Однако редакция Together Designer Community Edition основана на той же самой XML-платформе, что и коммерческие редакции Together. В одном и том же проекте можно использовать и коммерческую редакцию Together, и редакцию Community Edition.

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

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

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

Н.Е.: Многим российским читателям известно, что разработка Together ведется в России, и многие из нас этим гордятся. А насколько велика ваша команда?

П.К.: Сейчас у нас около 80 человек в санкт-петербургском отделении, и есть еще несколько человек, которые работают над средствами интеграции с StarTeam и Caliber. Взаимодействие инструментов моделирования со средствами управления требованиями и изменениями нам представляется очень важным, и этому уделяется огромное внимание.

Интересно, что в команде Together по-прежнему работают люди, стоявшие у истоков этого проекта, а это было очень давно — первая «инкарнация» LiveSource появилась еще в середине 90-х годов. Историю Together можно проследить с 1996 года, с инструмента CASE++ для визуализации кода для C++, который создали Дитрих Каризиус и Александр Аптус. Позже появились поддержка UML 1.3, средства аудита кода и проектирования данных, поддержка EJB и средств управления требованиями и тестирования, поддержка JDK1.4 и широкого спектра языков программирования, редакции для Eclipse, JBuilder, Visual Studio.

Н.Е.: А что вы можете рассказать об ожидаемых версиях Together?

П.К.: Сейчас у нас есть продукт Together Architect, который более функционален и заменит редакцию Together Control Center. Кроме того, имеется Together Edition для JBuilder, поддерживающий технологию Live Source, а также Together Editon for Visual Studio .NET и, наконец, Together for Eclipse.

Together Designer 1.0 — это наш первый коммерческий продукт для бизнес-аналитиков. Он поддерживает UML 2.0, коллективную разработку, контроль версий, генерацию документации, шаблоны проектирования. Затем появится Together Developer for JBuilder, обладающий средствами интеграции со средой разработки JBuilder 2005 (этот продукт был выпущен ранее в этом году. — Н.Е.).

В начале 2005 года мы должны превратить другие наши инструменты в средства поддержки UML 2.0. Будут выпущены обновления для Together for Eclipse, Together for Visual Studio .NET 2005 (речь идет о версии продукта, которому посвящена данная статья. — Н.Е.), а в середине года выйдет вторая версия редакции Together Architect, которая будет первым инструментом, поддерживающим технологию MDA-преобразований.

Н.Е.: Коль скоро зашла речь об MDA, то как обстоят дела с интеграцией Together с Delphi? Несмотря на активное продвижение Visual Studio на российском рынке, в нашей стране Delphi — пока еще одно из самых популярных средств разработки.

П.К.: В Delphi 8 Architect были средства визуализации кода, которые использовали технологии Together, но это не полный LiveSource. Мы делаем все для поддержки Delphi, но все равно пройдет еще какое-то время, прежде чем пользователи получат ее полнофункциональную реализацию.

Н.Е.: Правильно ли я понимаю, что поддержка MDA будет реализована в редакции Together Architect?

П.К.: Поддержка MDA не может появиться в продуктах Together немедленно: мы реализуем в Together Architect не зависящее от платформы моделирование, а для поддержки MDA нам нужно создать модель, зависящую от платформы, и средства преобразования ее в код.

MDA — действительно интересная технология, равно как и ее реализации в Delphi — и Bold, и ECO. Но ECO, к сожалению, зависит от чтения некоторых хранимых данных на этапе выполнения, а также от конкретной среды. В этом случае необходимо точное преобразование модели в код, основанное на метамодели.

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

Н.Е.: А есть ли стандарт на преобразование модели в код для MDA?

П.К.: Пока нет — в этом-то и проблема. Спецификации на преобразование модели, не зависящей от платформы, в зависящий от платформы код еще нет — мы ждем ее появления.

Н.Е.: Да, без стандарта и у разработчиков, и у вас через несколько лет возникнут проблемы, связанные с нестандартными преобразованиями моделей в код…

П.К.: Именно так. Если будет стандарт — мы на его основе создадим средства преобразования модели в код. Если их сделать, не дожидаясь появления стандарта, можно произвести инструмент, который потом не будет ему соответствовать. Можно, конечно, думать о продуктивности создания нынешних проектов, но необходимо предвидеть, что будет с такими проектами через несколько лет.

Н.Е.: Но если требования MDA к качеству модели очень высоки, имеются ли способы проверки качества моделей? Не секрет, что многие разработчики и архитекторы боятся получить от аналитиков или от заказчиков модель низкого качества, так как им придется реализовывать все, что будет в ней содержаться.

П.К.: Вы правы. Я видел не так много качественных моделей, на основе которых можно создать работающую реализацию. Сейчас существуют средства проверки качества кода, но не менее важно получить и средства контроля качества разработки, не зависящей от платформы, то есть контроля качества модели. Как минимум, такие средства должны проверять, все ли ограничения, правила и ассоциации описаны корректно, удовлетворяет ли модель стандартным шаблонам дизайна, правильно ли построено дерево наследования классов. Поэтому следующее поколение Together Designer будет включать средства проверки качества модели и соответствующие метрики, позволяющие применять их при минимальном прерывании процесса моделирования и разработки. Таким образом, то, что мы уже сделали для разработчиков (то есть метрики кода), мы сделаем и для бизнес-аналитиков.

Н.Е.: И когда ждать инструментов проверки качества моделей?

П.К.: В начале 2005 года мы должны определить и реализовать эту технологию для всех поддерживаемых платформ — Eclipse, JBuilder, Visual Studio .NET.

Н.Е.: Ну что ж, будем ждать новых версий. И спасибо за хорошие продукты!