Диссертация (Платформа для создания специализированных визуальных сред разработки программного обеспечения), страница 7

На ранних стадиях развития компьютерной техники процессразработки программ состоял из непосредственно программирования. В этомпрограммистам помогали редакторы текста, трансляторы этих текстов программ вассемблерные и бинарные машинные коды, линковщики и загрузчики. С ростомсложности создаваемых систем и подходов к их разработке набор доступныхразработчикам инструментальных средств стал существенно расширяться. Вчастности, повысилась ценность стадий анализа и проектирования создаваемого ПО,37тестирования, верификации программ и т.п., а вместе с ними и инструментов,автоматизирующих данные виды деятельности.С начала 1980-х годов в активное обращение входит термин CASE-инструмент(Computer Aided Software Engineering), изначально используемый для описаниялюбых инструментов, используемых для автоматизации разработки ПО: редакторовтекста и документации, компиляторов и кодогенераторов, отладчиков, хранилищданных и репозиториев и т.п.

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

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

Появляется понятие CASE-инструментария или CASEпакета (CASE workbench) [86], т.е. программного средства, интегрирующего в себенесколько CASE-инструментов: например, в случае текстовых языков, это можетбыть среда разработки, в состав которой входят текстовый редактор с подсветкойсинтаксиса, компилятор и отладчик. В целом считалось, что использование CASEинструментариев помогает упорядочить и стандартизировать процесс разработки([57, 58, 130]), тем самым снизить время и затраты, затрачиваемые на создание ПО,повысив его качество ([57, 63, 51, 84, 130, 134]), иметь единый источник знаний опроекте ([119]), автоматически получать документацию о системе по создаваемыммоделям ([74, 154]), повышать тестируемость и сопровождаемость системы ([82]) ит.п.Однакотакжеактивнообсуждалисьинедостаткисуществующих38инструментариев, большей частью ориентированность на определенные этапыразработки, сложность интеграции друг с другом для формирования единогопроцесса [87, 125, 149] (более подробно о критике CASE-инструментов см.

вПриложении А). С появлением инструментальных сред, поддерживающих полныйцикл процесса разработки ПО в соответствии с выбранной методологией, в оборотвходиттерминCASE-средаилиCASE-окружение(CASEenvironment).Соответственно, подходы к разработке, подразумевающие активное использованиеподобных инструментов, называют CASE-подходами. Подобная терминологиясохраняется и по сегодняшний день.

Исходя из того, что в настоящее времяинструментальные средства редко используются в отрыве друг от друга инаибольшую пользу дают при совместном применении, в данной работе, если неуказано явно, термины “CASE-инструмент”, “CASE-инструментарий” и “CASEсреда” используются как синонимы.В 1990-х годах в попытке упорядочить и взять под контроль ход разработки ПОпопулярность набирают идеи о моделировании деятельности по созданиюпрограммных систем в виде процесса, вовлекающего работников компании вдеятельность по достижению определенных бизнес-целей компании.

При этомCASE-инструменты видятся как подходящее средство для автоматизации иформализации отдельных этапов процессов [83]. В отсутствии единого пониманиянабора и состава таких этапов многие компании пытаются выстраивать процессы,исходяизсобственныхособенностейипотребностей,чтоприводитксущественному росту количества создаваемых CASE-инструментов, большей частьюнесовместимых друг с другом. Ситуация меняется с появлением языка UML,разработанного консорциумом OMG для унификации представления моделей ПО.Появляютсяподходы,использующиеUMLвкачествеосновногоязыкамоделирования (например, RUP [95] или MDA [120]), и инструментальные средствадля реализации данных подходов в рамках производственного процесса (первым39инструментарием, поддержившим UML, был Rational Rose [19], ставший весьмауспешным коммерчески).2.3.

Состав типовой CASE-средыВнастоящееинструментариеввремя[23-25],существуетбольшеразличающихсякаксотниразличныхлицензиейCASE-распространения,границами своей применимости, так и качеством реализации и удобствомиспользования, однако набор инструментов, входящих в их состав, в большинствеслучаев совпадает.●Набор редакторов, с которыми работает пользователь среды, создавая моделиразрабатываемого ПО.

Чаще всего используются графические языки, моделина которых представляются набором диаграмм, однако нередко в составCASE-среды входит редактор табличных данных или текстов (для заданиядокументации, правки скриптов, конфигурационных файлов и т.п.). Для рядаинструментов также характерно наличие редактора форм, позволяющегозадавать пользовательский интерфейс разрабатываемого приложения.●Репозиторий, являющийся центральным хранилищем создаваемых моделей ипредоставляющий доступ к ним всем остальным компонентам среды.●Набор инструментальных средств, осуществляющих генерацию целевыхартефактов разработки по создаваемым моделям.

Тип и форма создаваемыхсущностей зависят напрямую от назначения каждого конкретного CASEинструментария. Это могут быть файлы с кодом на одном из текстовых языковпрограммирования (например, “скелеты” отдельных частей приложения в видефункций-заглушек или полноценный код, готовый к компиляции, если вмодели достаточно информации для его генерации), автоматические тесты илитехническая документация для создаваемого кода, различные отчеты идокументация по созданным моделям, скрипты сборки и размещения,40инсталляторы готовых версий создаваемого ПО и многое другое, дляавтоматизированного создания чего могут использоваться CASE-среды. В этужекатегориюможноотнестиинструментыавтоматическихилиавтоматизированных преобразований моделей (например, для осуществлениярефакторингов моделей или выполнения над ними часто повторяющихсярутинных операций).●Механизмы циклической разработки ПО (round-trip engineering), позволяющиедополнять “вручную” код, автоматически сгенерированный по моделям, так,чтобы изменения остались в силе при последующих перегенерациях.

Стоитотметить, что для CASE-средств, основанных на UML, наличие подобныхинструментов является крайне важным, поскольку UML является языкомпроектирования, и сгенерировать полноценный код возможно далеко не повсем UML-моделям.●Средства обратного проектирования (reverse engineering), позволяющиестроить модели по целевым артефактам (документации, коду и т.п.).●Средства эмуляции и отладки создаваемых систем или их частей. Для рядапрограммных систем отладка может происходить посредством генерацииисходного кода и отладки его с помощью соответствующих средств(например, запуска программ на языке C в отладчике gdb), однако частопроцесс отладки целевой системы может происходить и на уровне моделей(например, при дороговизне или требований особых условий для реальногозапуска системы).

В этом случае инструментальная среда может выдаватьпользователю наглядную информацию о ходе процесса исполнения (например,подсвечивая исполняемую в текущий момент часть модели).●Инструменты поддержки процесса командной разработки. Может бытьподдержана как синхронная командная работа (например, одновременноеизменение одной и той же диаграммы проектировщиками с разных41компьютеров посредством сетевого доступа к центральному репозиторию), таки асинхронная (например, посредством обмена изменениями в моделях междуCASE-средствами с помощью системы контроля версий).●Набор верификаторов и анализаторов создаваемых моделей, обеспечивающихкорректность целевого ПО и предоставляющих статистику по моделям всоответствии с используемыми в проекте метриками и т.п.●Библиотеки шаблонов и готовых решений для набора типовых ситуаций,возникающих при проектировании выбранного типа ПО.●Средства экспорта и импорта моделей для обеспечения возможности обменаданными между CASE-инструментами.●Набор пользовательской документации к данной CASE-среде — руководствапользователя, учебные пособия, механизм всплывающих подсказок во времяработы с системой и т.п.2.4.

Современные DSM-платформыСуществует два способа анализа DSM-платформ — можно анализировать самиmetaCASE-системы как среды разработки других визуальных сред и можноанализировать те DSM-решения, которые получаются на выходе подобных систем. Вданной работе нас больше интересует второй способ, поэтому DSM-платформыбудут рассматриваться не с точки зрения методологии или процесса созданиявизуальныхязыковиинструментовдляних[145],асточкизренияинструментальных средств в составе DSM-платформ, которые позволяют создаватьте или иные инструменты в DSM-решениях.В настоящее время существует целый ряд DSM-платформ, являющихся каккоммерческими, так и исследовательскими разработками.