Диссертация (1148239), страница 17
Текст из файла (страница 17)
В случае некорректных выражений (какна языке Си внутри блоков, так и некорректных диаграмм в терминах блок-102схем) выдается соответствующее предупреждение с указанием на проблемныйблок.●Генератор исходного кода, дающий возможность получить по диаграммепрограмму на языке Си. При генерации проверяется синтаксическаякорректность диаграммы (неструктурные диаграммы не поддерживаются, вэтом случае выдается предупреждение). Корректность кода внутри блоков непроверяется, текст просто копируется без изменений в целевой выходнойфайл.●Визуальный отладчик диаграмм осуществляет генерацию по диаграммефайлов с исходным кодом на Си, осуществляет компиляцию его в отладочномрежиме, после чего запускает отладчик GDB [33], загружает в негоскомпилированный бинарный файл и позволяет осуществлять его пошаговуюотладку.
При этом каждый блок диаграммы привязывается к сгенерированнымпо этому блоку строкам (одной или нескольким) в файле исходных текстов.Это позволяет в процессе отладки подсвечивать блок, которому соответствуетисполняемая в отладчике строка кода. Возможно также выполнение некоторыхкоманд GDB посредством интерфейса QReal: построчное выполнениепрограммы, установка точек останова и переходы между ними, завершениеотладки. При выборе соответствующих пунктов в меню QReal нужная командапередается в запущенный экземпляр GDB, после чего в информационном окнеQReal отображается вывод отладчика после выполнения данной команды.Как было отмечено выше, изначально описанные инструменты былизапрограммированы вручную, однако в дальнейшем интерпретатор и отладчик былиописаны с помощью средств описания исполнимой семантики.103Рисунок 23.
Внешний вид среды, основанной на языке блок-схем6.4. Среда разработки QReal:UbiqНа кафедре системного программирования СПбГУ уже несколько летразрабатывается платформа Ubiq Mobile [37], упрощающая создание мобильныхприложений, являющихся компонентами распределенных информационных систем.Такие системы характеризуются большим числом пользователей, сложной бизнеслогикой, выполняемой большей частью на сервере, а также большим набороммобильных платформ, на которых будут работать создаваемые приложения. Типовоеприложение, создаваемое с помощью Ubiq Mobile, состоит из сервера и мобильногоклиента (или набора клиентов), общающихся между собой посредством протокола,определяемого платформой. Платформа инкапсулирует в себе большую частьспецифики, связанной с клиент-серверным взаимодействием, работой на мобильномустройстве и т.п., предоставляя удобные средства разработки кроссплатформенных104мобильных приложений C#-программистам, не владеющим специальными навыкамипрограммирования под мобильные устройства.
Целью проекта QReal:Ubiq сталосоздание среды визуального программирования приложений с помощью платформыUbiq Mobile, которая позволила бы еще больше упростить процесс разработкимобильных систем за счет замены программирования на C# моделированием и,следовательно, расширить круг людей, которые могут создавать такие приложениясамостоятельно.Первая версия QReal:Ubiq была создана в 2011 году и представлена наконференции FRUCT 2011 [72].
Данное решение позволило повысить наглядность ипонятность программ, не требовало от разработчика глубоких знаний объектноориентированного программирования, однако все же для создания приложений былонеобходимо писать в блоках довольно много текстового кода, а также пониматьобщее внутреннее устройство платформы Ubiq Mobile. В дальнейшем былапредпринята попытка ограничения предметной области целевых мобильныхприложений и создания инструментов для их моделирования, которые бы нетребовали от проектировщика знания целевого языка программирования (C# вслучае платформы Ubiq Moblie).
Так, был выбран класс онлайн игр для двухпользователей с игровым полем (например, “Морской бой”, “Крестики-нолики” итому подобные игры), а также класс простых информационных приложений (такназываемые,приложения-визитки,отражающиестатичнуютекстовуюимультимедийную информацию, размещенную на ряде экранов). В результате былисозданы следующие инструменты.1. Редактор экранных форм, позволяющий схематично описывать внешнийвид экранов приложения.
Каждому элементу управления возможнозадать имя обработчика события, с ним связанного. Простые переходымежду экранами (например, переход на заданный экран при нажатии накнопку) возможно задавать прямо на этой диаграмме с помощью105специального вида связей. Пример диаграммы, задающей экраннуюформу приложения для игры в “Морской бой”, см. на рис. 24.2. Редактор логики обработчиков событий позволяет задать алгоритмобработки событий элементов управления.
Язык содержит в себеоператоры условий, циклов, поддерживает работу с переменными ипозволяет считывать и изменять параметры элементов управления наэкранных формах. На рис. 25 приведен пример диаграммы, котораяпроверяет условие завершения игры и выполняет соответствующуюинициализацию внутренних переменных приложения.3.
Редактордиаграммнетривиальныелогическихлогическиеусловийвыражения,позволяеткоторыемогутзадаватьбытьвдальнейшем использованы в операторах на диаграммах обработчиковсобытий. На рис. 26 приведен пример диаграммы, описывающей условиевыигрыша одной из сторон.4. Генератор исходного кода позволяет по созданным диаграммамавтоматически получить код прототипа соответствующего приложенияна языке C# с использованием средств платформы Ubiq Mobile.106Рисунок 114. Диаграмма редактора форм QReal:Ubiq107Рисунок 12. Пример диаграммы обработчика событий для игрового поля108Рисунок 13. Пример диаграммы, описывающей условие завершения игры6.5.
Редактор диаграмм машин состояний для проектакомпьютерного зренияРедактор диаграмм машин состояний был создан при работе над проектом вООО “Системы компьютерного зрения”. Проект был нацелен на создание системыуправления телевизором взмахами руки вверх-вниз и влево-вправо. Так как припроектированииархитектурырешениябылоприняторешениеосновыватьреализацию на машинах состояний, с помощью QReal был создан подходящейграфический язык и соответствующий генератор кода на С++.
Язык состоял изчетырех типов элементов: начальное состояние, состояние завершенного жеста,109состояние незавершенного жеста и таймер, который присоединялся к элементусостояния, в который переходило управление по истечении определенногопромежутка времени неактивности системы. Интересной особенностью языка игенератора стало то, что это был неграфовый язык: помимо связей междуэлементами имело значение и геометрическое расположение элементов надиаграмме. Так, движение руки вправо переводило автомат в правое состояние,возврат руки в начальное положение — возврат в среднее состояние ожидания.Пример создаваемых на данном языке диаграмм см.
на рис. 27.Рисунок 147. Пример диаграммы машин состояний для проекта компьютерногозрения6.6. Сравнение DSM-платформДля сравнения функциональности разработанной платформы QReal с наиболее110популярными аналогами и доказательства соответствия полученных результатовцелям работы был проведён следующий эксперимент.В дополнение к платформе QReal было выбрано ещё две программныхсистемы:MetaEdit+,котораяявляетсянаиболеераспространённойсредикоммерческих платформ, и Eclipse Sirius – наиболее зрелый открытый продукт,построенный на базе Eclipse Modeling Project.
Была поставлена задача созданиявизуальной среды для описания схем данных, основанной на нотации Чена«Сущность-связь» [73]. Разрабатываемая среда в идеале должна содержать: визуальный редактор; генератор скриптов на языке SQL DDL для создания баз данных; механизм ограничений, проверяющий, что любая сущность надиаграмме имеет хотя бы один атрибут; средство осуществления рефакторинга моделей, позволяющее выделитьряд атрибутов в отдельную сущность.Поставленную задачу выполняли совместно два человека, до этого имевшихопыт работы со всеми перечисленными платформами. Замерялось время созданияинструментов, результаты отражены в таблице 2.Очевидно, что полученные результаты могут характеризовать эффективностьразработанных средств лишь в первом приближении. Для более аккуратногосравнения необходимо провести масштабный эксперимент, в котором примутучастие не менее 10 человек разной квалификации и степени знакомства стестируемыми платформами.
Кроме времени выполнения задач необходимо ввести идругие метрики: степень соответствия решения постановке задачи, количествовыполненных операций (например, открытых экранов, нажатий мышью, длина пути,пройденного курсором мыши) и т.п. Также следует оценивать субъективную оценкуоб удобстве использования и удовлетворённости полученным результатом. Кромеэтого в эксперимент требуется добавить задачу создания поведенческого языка111(например, языка описаний сетей Петри).
Это позволит также сравнить средстваплатформ для создания интерпретаторов и отладчиков такого рода языков. Также всписоксоздаваемыхинструментовследуетдобавитьсредстваподдержкимногопользовательской работы при работе с диаграммами и другие инструменты изп. 2.5. Всё это требует аккуратного планирования и серьёзных ресурсов. Подобныйэксперимент будет проведён после устранения пробелов в документации иобучающих материалах платформы QReal, выявленных в рамках описанноготестирования.Таблица 2.