Cемейства программных продуктов. DSM-подход

Повторное использование средств разработки

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

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

Во-вторых, компания может потратить значительные ресурсы для более "тонкой" настройки и тесной интеграции этих средств в единую среду разработки. Например, можно разработать специальный скрипт, который через интерфейс командной строки запускает компилятор С++ Microsoft Visual Studio для автоматической пакетной сборки всех проектов. При этом исходные тексты программ он "берет" из средства конфигурационного контроля Microsoft Visual SourceSafe. После окончания сборки скрипт посылает письма группе ответственных лиц о результатах, например в виде удобного HTML-отчета с возможностью быстрого доступа к логам сборки. Также можно создать скрипт, который по изменении версии продукта автоматически меняет его номер и в ресурс-файлах проекта, и в файлах с документацией, созданных в Adobe PageMaker и хранимых в XML-формате, и в файле readme.txt (составной части поставки продукта), который является обычным текстовым файлом. При этом все файлы берутся из Microsoft Visual SourceSafe, из определенных, заранее установленных мест. Могут также создаваться различные "мосты", "миграторы" данных и так далее. В целом все это может оказаться значительной работой, несмотря на начальную простоту исходных задач (аппетит приходит во время еды!).

В-третьих, в некоторых ситуациях компания может позволить себе создать собственные средства разработки, если: (i) стандартные не в состоянии удовлетворить потребности данного семейства; (ii) оборот проектов семейства значителен (их число, цена, количество задействованного персонала); (iii) затраты на создание новых средств разработки приемлемы. Разумеется, перед принятием такого решения все эти факторы должны тщательно анализироваться для снижения рисков. При этом нужно учитывать не только затраты на создание таких средств, но и планировать сопровождение - на практике это часто оказывается слабым местом.

Предметно-ориентированное моделирование (DSM-подход)

При внедрении стандартных средств визуального моделирования, если требуется эффективная кодогенерация, то необходима серьезная настройка таких средств. Это связано с необходимостью валидации и отладки визуальных моделей, созданием средств циклической разработки (round-trip engineering) - как-то обидно полностью сгенерировать код по моделям, а потом отлаживать и дописывать этот сгенерированный код, забыв про исходные модели, на которые было потрачено столько сил. Необходима также интеграция "ручного" кода со сгенерированным, интеграция графического пакета с другими средствами разработки и т. д. Объем этих работ часто бывает весьма значителен, так что возникает потребность в их четком планировании. Фактически, такая "настройка" часто оказывается отдельным проектом, и немаловажной задачей здесь становится не только создание решения, но и его поддержка. Все эти вопросы подробно обсуждаются в [10.10], [10.11].

В настоящее время на рынке существует значительное количество средств для разработки графических редакторов - с возможностью задать собственную графическую нотацию, создать в автоматизированном режиме сам графический редактор с репозиторием, браузером модели и т.д. Такими средствами являются Eclipse/GMF, Microsoft DSL Tools, Microsoft Visio 2003. С их помощью несложно разработать графический редактор, даже если вы делаете это в первый раз. А результат получается впечатляющим - богатый пользовательский интерфейс, обширные функциональные возможности, полный учет особенностей той задачи, для которой предназначается целевое средство. Такой подход к использованию визуального моделирования получил название предметно-ориентированного моделирования ( DSM-подход^{1Domain Specific Modeling} ).

Ниже приводится несколько примеров использования DSM-подхода в семействах программных продуктов.

Для разработки семейства телекоммуникационных систем потребовался новый язык визуального моделирования, среда проектирования и генератор результирующего кода. Наличие таких средств оказалось критичным для всего семейства, так как (i) позволило решить непреодолимую до сих пор проблему общения инженеров и программистов, (ii) стало "козырем" в борьбе за новые проекты в данной области. Использование готовых решений при создании этой среды было затруднительно в силу военной секретности разработок и вытекающих из этого ограничений на использование коммерческого ПО. А также из-за особенностей платформы реализации систем и общей "бедности" рынка средств графического проектирования на тот момент (дело было в начале 90-х годов прошлого века). Будучи созданными, данные средства использовались потом более десяти лет, на их основе были созданы десятки систем.

Другой пример. Компания, занимающаяся массовым выпуском небольших Интернет-сайтов, решила максимально оптимизировать свой процесс разработки для того, чтобы наладить потоковый выпуск таких продуктов. Только в этом случае разрабатывать сайты по цене $500-$1000 оказывается выгодно, а рынок таких сайтов велик. В числе прочих средств разработки был создан небольшой визуальный язык и редактор для определения требований к контенту будущего сайта. Именно детали контента (количество сущностей, наличие связей) оказались критичны для определения цены небольших сайтов. Для созданного редактора был реализован также генератор кода в среду разработки, используемую в компании. Кроме прочих выгод данного DSM-решения, генерация позволила быстро получать по требованиям заготовку сайта и сэкономить еще примерно один час работы (в целом разработка таких сайтов составляет приблизительно 16-20 человеко/часов, так что лишний час - это существенно).

Определения

Вот несколько определений, которые понадобятся в дальнейшем. Предметная область (problem domain, domain) - это часть реального мира (люди, знания, бизнес-интересы и др. активы), объединенная в одно целое для удовлетворения определенных потребностей рынка. Вот примеры предметных областей:

• некоторый бизнес-проект, объединяющий конкретных людей, которые хотят заработать на некоторой идее;
• сообщество людей внутри некоторой бизнес-области, например, сообщество Linux-разработчиков^{2http://www.linux.org/.} ;
• область академических исследований, например, изучение проблем разработки web-приложений.

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

Предметно-ориентированный язык (Domain Specific Language - DSL) - это язык, который создается для использования в рамках некоторой предметной области. Здесь рассматриваются только визуальные предметно-ориентированные языки.

DSM-решение - это конкретный DSL, метод его применения и средства инструментальной поддержки, внедренные в конкретный процесс разработки ПО. Факт внедрения очень важен и достигается, порой, большой работой, проделанной уже после того, как язык, метод и программные средства готовы.

DSM-пакет (DSM-продукт, DSM-инструменты) - часть DSM-решения, соответствующих программным средствам. Поскольку существенной частью таких средств является графический редактор нового языка, то далее вместо довольно-таки громоздкого термина "DSM-пакет" часто будет использоваться термин "графический редактор".

DSM-платформа - это инструментальная технология разработки DSM-решений. Можно выделить четыре типа DSM-платформ:

1. Полноценные среды разработки DSM-пакетов (например, Eclipse/GMF, Microsoft DSL Tools).
2. Конфигурируемые и надстраиваемые графические пакеты (например, Microsoft Visio, MetaEdit+, AutoCAD).
3. Различные библиотеки для создания отдельных компонент DSM-пакетов - графические библиотеки, библиотеки для работы с данными (например, Eclipse/EMF) и т. д.
4. CASE-средства, имеющие хорошие программные интерфейсы, встроенные скриптовые языки, модульную архитектуру и т. д. (например, Borland Tother Control Center, IBM Rational Rose).

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

О типовой структуре DSM-пакета

Созданием DSM-пакетов должны заниматься обычные software-компании, которые не специализируются на разработке визуальных средств, а имеют свои собственные проекты, в которых планируемый DSM-пакет должен принести определенную пользу. Поэтому создание таких пакетов должно быть им по силам. Это, с одной стороны, достигается путем использования DSM-платформ, реализующих такие трудоемкие компоненты, как графические средства, репозиторий, среду. С другой стороны, функциональность целевого DSM-пакета должна быть четко определена, чтобы не делалось никакой лишней работы. То, что может позволить себе, например, один из лидирующих продуктов на рынке средств визуального моделирования - пакет Borland Together Control Center, - часто непосильно для "рядовых" DSM-решений.

Определим теперь состав типового DSM-пакета.

• Среда - это реализация общих сервисных функций DSM-пакета, таких как главное меню и панель инструментов с функциями создание/удаление/открытие/закрытие диаграмм и всего проекта, печать диаграмм, настройка цветов, шрифтов, толщины линий, геометрии и пр. Среда обычно включает в себя несколько рабочих областей - поле для рисования, браузер проекта, окна отладки, диагностики, палитру с элементами графической нотации DSL. Среды могут существенно различаться по предоставляемому набору функциональности: от поддержки минимального набора простейших функций до сложных сред с реализацией многопользовательской работы с моделями, интеграцией со средствами контроля версий и т. д.
• Графический редактор - основная рабочая область для рисования диаграмм с возможностью расположения на ней различных фигур (экземпляров графических конструкций языка), применения к этим фигурам набора операций (наполнение текстом, растягивание/сжатие, передвижение, группировка, разбиение на слои, соединение друг с другом линиями и т. д.), задания для них различных графических свойств (выбор толщины линий, цвета, свойства шрифтов). Кроме того, редактор может поддерживать различные функции над диаграммами, такие как переключение между несколькими режимами отображения конструкций, навигацию (через запросы и подсветку найденных сущностей), специфические функции - автоматическую нумерацию элементов, различные варианты автоматического размещения элементов на диаграмме (layout) и т. д.
• Браузер - средство просмотра и редактирования графа модели. Браузер должен быть синхронизирован с диаграммами.
• Репозиторий - единое хранилище информации о визуальных моделях, создаваемых в DSM-пакете, с возможностью быстрого доступа во время работы графического редактора.
• Генераторы - средства автоматического порождения программного кода по моделям, а также, возможно, и других артефактов, например текстовых и табличных документов, тестов. Сюда же отнесем средства импорта/экспорта моделей в различные форматы.
• Run-Time – это средства поддержки периода исполнения генерируемого по моделям нашего DSL программного кода. Нужен далеко не всегда, но часто – при реализации в DSM-решении уникальной кодогенерации. Если мы реализуем свою собственную генерацию для Java-классов, то никакого run-time нам, разумеется, не нужно - в его роли выступает Java-машина. Но если мы создаем собственный язык конечных автоматов и хотим, чтобы по таким спецификациям автоматически получался работающий код, то одной генерацией нам не обойтись. Необходимы также общие средства для всех моделей нашего языка, поддерживающие посылку/прием сообщений, механизм реализации параллельной работы конечно-автоматных компонент и многое другое. Весь этот код, как правило, не генерируется для каждой новой модели нашего языка (он ведь один и тот же!), а линкуется к ней. Генерируются лишь вызовы соответствующих процедур поддержки. Проектирование и реализация run-time (когда он нужен) является одной из самых трудоемких задач при реализации DSM-решения. Кроме того, при эволюции DSM-пакета, в частности, при его переносе на другую исполняемую платформу, меняется, как правило, именно run-time, а генератор кода и графический редактор затрагиваются в существенно меньшей степени.
• Средства проверки корректности моделей - отладчики модельных спецификаций, валидаторы моделей, средства тестирования в терминах моделей и т. д.
• Прочие компоненты, интегрированные с графическими редакторами и предназначенные для смежной деятельности, - например, диалоговый редактор текстовой части графического языка.

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

Интегрируемость DSM-пакета в среду программирования, используемую разработчиками, является важным условием его успешного применения. Например, реализация отладки визуальных спецификаций требует интеграции с отладчиками нижнего уровня - Java- или .Net-отладчиками, - чтобы не создавать для отладочного исполнения визуальных моделей свое собственное исполняемое ядро. Естественно, выбор отладчика нижнего уровня во многом диктуется той средой разработки, которая используется в проекте.

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

По этим причинам единственной, универсальной DSM-платформы быть не может. При проектировании DSM-решения разработчики должны выбрать подходящие средства из имеющихся на рынке сообразно своей ситуации. Рассмотрим три самых зрелых DSM-платформы - Microsoft DSL Tools, Microsoft Visio и Eclipse/GMF. Перейдем к их обзору.