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

Болеефункционально сложные (и востребованные пользователями) DSM-решения такжемогут содержать большую часть средств, описанных в разделе 2.3.СовременнаяплатформаDSMавтоматизированногосозданиядолжнаобладатьрешений,инструментамиобладающихдляследующейфункциональностью. Набор редакторов (графических и текстовых), реализующих набортиповых операций:o механизм отмены совершенных действий;o копирования-вставки элементов диаграмм;o средства декомпозиции и построения иерархий моделей;o поддержканесколькихвизуальныхсоздаваемых с их помощью моделей. Репозиторий для хранения моделей.языковиинтеграции48 Средства преобразования моделей (как в другие модели, так и в текст). Средства интерпретации/отладки создаваемых диаграмм. Средства многопользовательской работы. Анализаторы и верификаторы моделей. Средства интеграции со сторонними инструментами (например, средстваэкспорта и импорта моделей или открытый API для взаимодействия скомпонентами системы).Отметим, что важный для средств на основе UML механизм циклическойразработки ПО (round-trip engineering) в рамках DSM-парадигмы теряет смыслблагодаря тому, что полноценный код разрабатываемой системы генерируетсяавтоматическиипоследующееего«ручное»редактированиезапрещается.Использование средств обратного проектирования (reverse engineering) при DSMподходе в литературе не нашло своего отражения, хотя не видится техническихсложностей для создания их в metaCASE-средствах (по аналогии со средствамизадания генераторов кода или трансформаций моделей).2.6.

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

Данное исследование призвано49исследоватьвопроссозданияединойплатформы,позволяющейполнофункциональные решения в соответствии с этими требованиями.строить50Глава 3. Подходы к повышению удобствамоделирования3.1. ВведениеКакпоказановПриложенииA,помнениюбольшогоколичестваисследователей, одной из главных причин отказа от массового использованиясредств визуального моделирования и проектирования является их чрезмернаясложность, перегруженность функциональностью и неудобство в использовании вповседневныхпроцессахразработки.Неудобствоиспользованиятакихинструментов складывается в первую очередь из неудобства самого инструментария(много рутинных операций, сложный для понимания интерфейс, нетривиальныйпроцесс), так и из неудобства используемого языка моделирования.

Упомянутыеработы относятся к 90-м годам XX века, т.е. к CASE-средствам, основанным на UMLи крупных методологиях разработки ПО (например, Rational Unified Process, RUP),которые создавались исходя из соображений общности и единообразия, а неудобства использования (возможно поэтому ожидаемый методологами CASEподхода массовый переход на визуальное программирование в девяностых годах таки не произошел). DSM-решения призваны исправить ситуацию с удобством языковмоделирования,предлагаяпроектировщикамоперироватьнеабстрактнымиклассами или объектами, а вполне конкретными понятиями из целевой предметнойобласти. Однако, проблема сложности и неудобства визуальных сред разработкиостается и при использовании предметно-ориентированных языков: проектировщикув процессе моделирования приходится совершать большое число рутинныхдействий, что не лучшим образом сказывается на привлекательности и технологии вцелом.Даннаяглавапосвященавопросамулучшенийудобствавизуального51моделирования с точки зрения используемых инструментов.

В частности,рассматривается новый метод для создания инструментов распознавания жестов вдиаграммных редакторах.3.2. Использование распознавания жестов мышьюЭффективностьлюбогоиспользуемогоинструментаопределяетсятем,насколько удобно и быстро он позволяет выполнять те операции, для которыхпредназначен. В процессе разработки моделей одними из наиболее частовыполняемых действий над объектами на диаграммах являются их создание иудаление.В большинстве визуальных сред разработки для того, чтобы создатьнужный объект на диаграмме, необходимо найти его либо на панели инструментов,либо выбрать в меню, а затем указать место на диаграмме, где бы мы хотели этотэлемент разместить. Также в большинстве инструментариев возможен вариантсоздания объектов «перетаскиванием» (drag-and-drop) их из палитры.

При этом надоучитывать, что количество видов диаграмм и объектов в палитре каждой диаграммыможет быть довольно большим (например, 13 видов диаграмм в одном толькоUML 2). Не всегда возможно оставить в палитре только специфичные для данноготипадиаграммэлементы,посколькуможетвозникатьзадачабыстрогопрототипирования с использованием нескольких языков на одной диаграмме.

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

Возможным решением в такихслучаях было бы по жесту предоставлять список команд, из которых пользовательможет выбрать. Но если список будет слишком большим или будет вызываться прикаждом жесте мышью, то смысл введения жестов пропадает, так как большинствоинструментов уже предоставляет пользователю список объектов, которые спомощью операции drag-and-drop можно перетаскивать на рабочее поле.Данная идея уже нашла свое воплощение в инструментах моделирования VisualParadigm [21] и Ideogramic UML [13, 78]. К примеру, в Visual Paradigm выделяютсятри вида жестов — для создания объектов, для создания связей и для вызоваопределенных команд. Каждый жест задается набором направлений (вверх, вниз,влево,вправо),значениежестапомимопоследовательностинаправленийопределяется также и текущей диаграммой.

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

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

Основной принцип данного метода состоит в том,что создание инструментов распознавания жестов мыши для редактора нового языкапроисходит автоматически по описанию конкретного синтаксиса без участияразработчика этого языка.Основные этапы предлагаемого метода представлены ниже.1. Формальное описание внешнего вида элементов языка.2. Генерация по этим описаниям «идеального жеста» для каждого элемента.3.

Выполнение жеста мыши при моделировании с использованием языка.4. Сопоставление введённого жеста с набором «идеальных жестов» исоздание на диаграмме наиболее подходящего элемента.Отметим, что, хотя первый этап требует явных действий разработчика языка,внешний вид элементов языка неизбежно задаётся им в процессе создания редактора(независимо от используемой методологии разработки языка).В рамкахпредлагаемого подхода используются уже созданные ранее описания конкретногосинтаксиса, дополнительных действий от разработчика языка не требуется.Ключевым понятием предлагаемого метода является «идеальный жест» – некийэталон траектории движения мыши, который ставится в соответствие каждому54объекту на диаграмме и с которым будет осуществляться сравнивание вводимыхпользователем жестов в процессе распознавания.

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