DRAKON.SU

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

Математико-механический факультет

Кафедра Системного Программирования

Колантаевская Анна Сергеевна

Исследование удобства процесса моделирования на базе DSM-платформы QReal

Бакалаврская работа

Допущена к защите.
Зав. кафедрой: д. ф. м. н., профессор А.Н. Терехов

Научный руководитель:
ст. преподаватель Брыксин Т.А.

Рецензент:
ст. преподаватель Литвинов Ю.В.

Санкт-Петербург, 2013

Введение

Рост программной отрасли в последние десятилетия делает все более актуальным вопрос об оптимизации как труда отдельного программиста, так и процесса разработки в целом.

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

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

Необходимость оптимизации и автоматизации в рамках работы как отдельных разработчиков, так и групп программистов больших компаний привела к появлению так называемых CASE-систем (Computer Aided Software Engineering), определяемых в широком смысле как ”инструменты и методы для поддержки инженерного подхода к разработке программного обеспечения на всех стадиях процесса” [10].

Особую нишу среди подобных решений занимают средства визуального моделирования и программирования: языки и соответствующие им среды разработки.

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

Главное преимущество визуальных языков — то, что они позволяют наглядно представить программные структуры, как, например, алгоритмы и данные, в противовес традиционным текстовым языкам программирования, где такие многомерные структуры закодированы в одномерные строки с помощью достаточно сложного синтаксиса.

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

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

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

Многие инструменты не используются вовсе, скорость внедрения других в производственный процесс очень невысока ([14], [8]).

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

Почему же не происходит массового перехода на визуальные средства программирования?

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

Какие существуют возможности совершенствования визуальных средств разработки с точки зрения удобства их использования и чем определяется такое удобство?

Целью данной работы является исследование возможных подходов к повышению удобства процесса моделирования.

На кафедре системного программирования математико-механического факультета СПбГУ уже несколько лет разрабатывается DSM-платформа QReal, позволяющая создавать редакторы предметно-ориентированных визуальных языков.

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

Глава 1. Обзор предметной области

1.1. Использование CASE-средств

CASE-системы (Computer Aided Software Engineering) определяются в широком смысле как ”инструменты и методы для поддержки инженерного подхода к разработке программного обеспечения на всех стадиях процесса” [10].

Под инженерным подходом подразумевается “четко определенная, хорошо координированная повторяемая деятельность, имеющая некоторое представление и осуществляемая в соответствии с определенными правилами и заданными стандартами качества" [11].

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

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

Расходы на программное обеспечение с каждым годом растут, и даже локальные улучшения производительности разработчиков будут означать существенную экономию ([6]).

Большинство исследований показывают, что использование CASE-инструментов может положительно воздействовать на качество ПО и эффективность работы специалистов [15].

Использование таких CASE-инструментов в противовес “ручному” программированию имеет много преимуществ:

● улучшает понимание системы сложно взаимодействующих между собой объектов, представляя их визуально;

● упрощает процесс создания и изменения произвольных участков программного кода, а также управления отдельными программными модулями;

● дает дополнительные возможности отслеживать изменения переменных, атрибутов и процедур через набор диаграмм;

● позволяет осуществлять итеративный переход от концептуальных моделей на логическом уровне (упрощающих восприятие, как указано выше) к деталям реализации системы;

● способствует повышению эффективности коммуникации разработчиков за счет сопроводительных свойств визуального представления программы.

Однако, несмотря на преимущества использования CASE-инструментов, существуют определенные сложности, связанные с их введением в производственный цикл.

Большинство исследований указывает на ограниченность использования CASE-инструментов. Многие инструменты не поставляются вовсе, отчасти в связи с высокой стоимостью, отчасти из-за предполагаемой сложности адаптации к производству. В отношении других инструментов можно говорить о лишь очень невысокой скорости внедрения в производственный процесс [14].

Согласно одному из исследований ([20]) лишь 24% компаний использовали CASE-инструменты в разработке.

В ходе опроса 53 компаний по данным [9] было обнаружено, что 39 из них (73.5%) не используют CASE-средства вовсе, из 14 же компаний, пытающихся вводить подобные инструменты в производственный цикл, 5 впоследствии были вынуждены от них отказаться.

Интервью ([15]), проведенные среди компаний, заявляющих об использовании CASE-инструментов, показали, что большая часть членов таких компаний по факту такими инструментами не пользуется.

В 57% участвующих в исследовании организаций менее чем 25% разработчиков использует СASE-инструменты.

Более современные исследования в целом показывают аналогичные результаты, по данным одного из них [8] в среднем после года внедрения 70% CASE-инструментов не используется вовсе; 25% CASE-инструментов используются лишь отдельными разработчиками; 5% CASE-инструментов широко используются, не актуализируя, однако, полный спектр своих возможностей.

Итак, несмотря на очевидные преимущества, в реальном промышленном программировании CASE-инструменты используются редко.

Почему же не происходит массового перехода на новые средства программирования?

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

Помимо стратегического решения компании об использовании CASE-технологии существует и решение конкретных разработчиков.

Что побуждает разработчика включить новый инструмент в свой арсенал разработки?

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

Авторы [19] и [5] также показывают, что наравне с перспективой повышения производительности не менее важным для программистов доводом, побуждающим к использованию нового инструмента, является удобство его использования, некоторые непосредственные выгоды от использования.

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

Так, например, часть опрашиваемых в исследовании [9] разработчиков, имеющих высокие ожидания в отношении прироста производительности, впоследствии были вынуждены отказаться от использования CASE-средств, в том числе вследствие их сложности.

Многие другие исследования также показывают, что CASE-средства являются излишне сложными, тяжелыми в использовании и требующими больших временных затрат на обучение ([15], [17], [18]).

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

Авторы [15] приходят к выводу, что, в частности, снижение сложности восприятия интерфейса инструментов способствовало бы повышению их используемости.

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

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

Авторы [19] показывают, что лишь небольшая часть возможностей CASE-инструментария используется разработчиками, и говорят о необходимости упора на доступность чаще употребимых функций.

Исследователи [13] также говорят об актуальности реализации простого и удобного и понятного интерфейса для доступа к наиболее часто используемым функциям в первую очередь.

Также многие авторы говорят о необходимости поддержки творческих процессов ([19], [7], [16]).

Сложности в обучении и необходимость разбираться с малопонятными интерфейсам заставляют разработчика сосредоточится на использовании инструментов или их освоении [12].

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

Плохо развитая поддержка разработки на ранних фазах жизненного цикла, ограничивающая проявления потенциала креативности ([15]) — еще одна причина, сдерживающая программистов от использования CASE-средств.

1.2. Язык ДРАКОН

Попытки создавать удобные графические средства разработки уже предпринимались.

Рассматриваемый далее язык ДРАКОН (Дружелюбный Русский Алгоритмический язык, Который Обеспечивает Наглядность) является одним из примеров удобных в использовании языков моделирования ([3]).

ДРАКОН — визуальный алгоритмический язык, разработанный в конце 80х – начале 90х годов XX века под руководством Владимира Паронджанова при участии Российской Академии Наук в рамках космической программы Буран.

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

Среди прочих задач, стоявших перед разработчиками, были:

● предоставление человеку языковых средств, упрощающие восприятие сложных процедурных проблем для уменьшения вероятности ошибок и роста производительности труда;

● улучшение качества программного обеспечения по критерию "понимаемость алгоритмов и программ".

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

Управляющие структуры языка ДРАКОН по замыслу разработчика специальным образом приспособлены к восприятию, делая, таким образом, представление программы еще более понятным, а программирование — еще более удобным.

На рис. 1 приведен пример ДРАКОН-схемы, созданной для определения кислотности раствора.

Рис. 1. Пример ДРАКОН-схемы.

Как и все прочие языки, ДРАКОН опирается на математику и логику. Однако сверх того, он самым тщательным образом учитывает когнитивные вопросы ([3], [4]).

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

По мнению создателей языка, именно благодаря систематическому использованию когнитивно-эргономических методов ДРАКОН приобрел свои уникальные эргономические характеристики.

1.2.1. Процесс моделирования на языке ДРАКОН

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

Создание любой ДРАКОН-схемы начинается с создания заготовки.

Заготовки бывают двух видов: одна используется для построения ДРАКОН-схемы “примитив”, из другой получается “силуэт” (рис. 2).

Рис. 2. Заготовки для построения ДРАКОН-схемы.

Первая заготовка — самая простая — может использоваться для создания “примитивов” — коротких, одноэтапных программ.

Программы, разделенные на несколько этапов, носят название “силуэтов”. Каждый этап представляется отдельной веткой. Первым оператором ветки объявляется название этапа.

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

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

Атомом называется элемент языка, который за одну транзакцию мы можем добавить в схему.

Атомы являются основными синтаксическими единицами языка ДРАКОН — словами или операторами, составляющими любую схему.

Атомы языка делятся на простые и составные, функциональные и нефункциональные.

Простые содержат одну икону, составные атомы (или шаблоны) не менее двух.

Функциональными являются все атомы, кроме оператора комментария. Полный список атомов см. рис. 3.

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

Ввод атома производится так: происходит разрыв соединительной линии в выбранной пользователем некоторой точке, после чего в место разрыва вставляется атом, как показано на рис. 4.

Рис. 3. Атомы языка ДРАКОН.

Атомы вставляются только в разрешенные места, которые называются валентными точками дракон-схемы.

Перечень точек включает:

● валентные точки заготовок;

● валентные точки на составных иконах;

● входы и выходы атомов.

Валентные точки схемы делятся на нейтральные и критические.

Точка является нейтральной, если применение операции “ввод атома” к данной точке является возможным, но не обязательным.

В отличие от нее критическая точка требует обязательного ввода атома.

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

При этом точки входа и выхода этого нового атома становятся нейтральными.

Рис. 4. Примеры операций ввода атома.

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

Ниже приведен пример конструирования ДРАКОН-схем на базе заготовки “примитив” (рис. 5).

Рис. 5. Конструирование ДРАКОН-схемы на базе заготовки “примитив”.

1.2.2. Визуальные особенности моделирования на языке ДРАКОН

Касаясь процесса создания программы, нельзя не сказать отдельно о связанных с ним непосредственно способах укладки элементов программы на рабочую область. От расположения элементов диаграмм на листе напрямую зависит их читабельность (для сравнения см. рис. 6 — разные варианты “раскладок” для одной и той же диаграммы).

Рис. 6. Пример разных “раскладок” диаграммы.

Исчисление, разработанное для ДРАКОНа, называется шампур-методом. Оно даёт возможность строить «слепыш» алгоритма, последовательно применяя правила построения к базовым заготовкам-шаблонам, получая на каждом шаге построения ДРАКОН-схему,
удобную для восприятия.

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

1) Принцип шампура — атомы-операторы, следующие в алгоритме безусловно друг за другом, т.е. представляющие собой прямую и непосредственную последовательность действий, упорядочиваются по вертикали, так что исполняемая первой икона всегда лежит сверху,
последняя — снизу, и все они лежат на одной оси.
Пример шампур-блока смотри на рис. 7.

Рис. 7. Пример шампур-блока.

2) Принцип главной/побочных вертикалей — выходы развилок, образующиеся при появлении условных операторов или ветвлений, упорядочены друг относительно друга так, что не лежащий на главной вертикали выход (называемый побочным) всегда располагается правее
главного.
То есть среди множества выходов “развилок”, выделяют основной, главный путь потока управления и располагают его на главной вертикали, прочие же ветви-шампуры справа от него (рис. .

Рис. 8. Иллюстрация принципа главной/побочных вертикалей.

1.3. QReal

Апробацию данной работы было решено осуществлять применимо к системе QReal2 — платформе предметно-ориентированного моделирования (DSM-платформе), позволяющей быстро и удобно разрабатывать новые визуальные редакторы, ориентированные на
специализированные визуальные языки, посредством описания их модели на метаязыке [1].

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

Дальнейшее расширение визуального языка метаредактора QReal некоторыми эвристиками, упрощающими разработку, позволило бы сделать процесс моделирования более удобным для всего ряда редакторов, описанных посредством такого расширенного языка в QReal.

1.3.1. Об архитектуре QReal

QReal — сложная система с многоуровневой архитектурой.

Каждый визуальный редактор, создаваемый QReal, является отдельным подключаемым модулем, а архитектура QReal как CASEсистемы включает в себя абстрактное ядро, поставляющее базовый функционал для всех редакторов (например, отрисовка элемента), и модули, реализующие специфики языков и одинаково разбираемые абстрактным
ядром (см. рис.9).

Отзыв научного руководителя
на выпускную квалификационную работу
студента 461 группы

Колантаевской Анны Сергеевны

“Исследование удобства процесса моделирования на базе DSM-платформы QReal”

Работа А.С. Колантаевской была посвящена исследованиям в области удобства процесса визуального моделирования.

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

Существует мнение, что отчасти это вызвано неудобством как существующих CASE-систем, так и самого процесса моделирования в частности.

Перед Анной Сергеевной была поставлена задача проанализировать существующие исследования на тему эргономизации процесса моделирования, выбрать несколько эвристик, повышающих удобство использования CASEсредств, и реализовать их в metaCASE-среде QReal.

В ходе выполнения работы Анна Сергеевна проанализировала существуюшие в печати исследования и анализы использования CASE-инструментов в промышленности, которые подтвердили проблемы с удобством использования этих средств.

Были также проанализированы некоторые попытки исправить подобную ситуацию.

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

Данные эвристики были выделены и часть из них была обобщена для применения в других визуальных языках.

В качестве апробации некоторые из этих обобщенных эвристик были реализованы в DSM-платформе QReal.

Реализация данной функциональности на уровне платформы позволила автоматически использовать их во всех визуальных средах разработки, созданных на базе QReal, однако потребовала от Анны Сергеевны дополнительных усилий в связи с более высоким уровнем абстракции сущностей “движка” платформы.

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

На мой взгляд, работа заслуживает оценки “отлично”.

Старший преподаватель Т.А. Брыксин