Диссертация (Методы и средства разработки графических предметно-ориентированных языков), страница 33
Описание файла
Файл "Диссертация" внутри архива находится в папке "Методы и средства разработки графических предметно-ориентированных языков". PDF-файл из архива "Методы и средства разработки графических предметно-ориентированных языков", который расположен в категории "". Всё это находится в предмете "технические науки" из Аспирантура и докторантура, которые можно найти в файловом архиве СПбГУ. Не смотря на прямую связь этого архива с СПбГУ, его также можно найти и в других разделах. , а ещё этот архив представляет собой кандидатскую диссертацию, поэтому ещё представлен в разделе всех диссертаций на соискание учёной степени кандидата технических наук.
Просмотр PDF-файла онлайн
Текст 33 страницы из PDF
В ходе проектабыли выявлены задачи, решение которых позволило бы уменьшить трудоёмкостьсоздания подобных систем. В целом DSM-подход показал себя полезным напрактике, и дальнейшие исследования в этой области помогли бы эффективно создавать специализированные среды визуального программирования и для гораздоболее узких предметных областей.Результат проекта — среда QReal:Robots — была представлена на «Открытыхсостязаниях Санкт-Петербурга по робототехнике» 2012 года и на робототехническом фестивале «Робофест 2012» в Москве. В качестве доказательства применимости этой среды к реальным задачам, решаемым школьниками с помощью среданалогов, команда студентов приняла участие в соревнованиях в движении роботапо линии с программой, реализованной на QReal:Robots.
Несмотря на то, что длястудентов кафедры системного программирования участие в соревнованиях сталопрактически первым опытом решения задач кибернетики, им удалось показатьдостойные результаты, уступив лишь специально созданным для этой задачироботам (которые по техническим характеристикам имели преимущество передроботами, собранными из конструктора Mindstorms NXT). На соревнованияхбыло проведено анкетирование школьников, которым было предложено решитьнекоторые простые задачи на QReal:Robots, результаты показали, что пользовательский интерфейс продукта достаточно хорош, чтобы вызвать у пользователей симпатию (подробнее об исследовании пользовательского интерфейсаQReal:Robots см.
в работе [134]). С использованием QReal:Robots было такжепроведено занятие в детском робототехническом лагере в г. Сиверский летом2012 года, где школьники успешно решили задачу движения робота по линии надвухмерной модели.Кроме соревнований, среда QReal:Robots представлялась на стендовых докладах при соревнованиях и на нескольких специализированных конференцияхшкольных учителей и методистов, где вызвала большой интерес среди учителей. Некоторые из них впоследствии обращались к автору с предложениемоказать посильную помощь в разработке и тестировании, некоторые использовалиQReal:Robots в своих занятиях. Таким образом, QReal:Robots можно считать175полноценным отчуждаемым продуктом, востребованным и имеющим реальныхпользователей, в том числе и не владеющих программированием.A.2. Среда программирования распределённыхмобильных приложений QReal:UbiqA.2.1.
ВведениеТак же, как и QReal:Robots, QReal:Ubiq появилась из практической задачи,с которой к нам обратились представители индустрии — программированиемобильных приложений в рамках архитектуры платформы Ubiq Mobile. В этомслучае также имелась достаточно узкая предметная область, но приложения,которые требовалось разрабатывать, были гораздо ближе к типичным разрабатываемым промышленно приложениям, чем QReal:Robots, в частности, имели инетривиальную логику, и пользовательский интерфейс. Поэтому данная задачабыла интересна как некоторая попытка заменить визуальным программированием программирование на текстовых языках для достаточно большого классазадач.
Успешная реализация подобной технологии открыла бы возможность длясоздания целой серии технологий, направленных на различные платформы.A.2.2. Постановка задачиПлатформа Ubiq Mobile [63] предназначается для создания распределённыхмобильных приложений со сложной серверной логикой, таких как бизнесприложения, многопользовательские игры и т.д. Архитектурно платформа представляет собой сервер с выполняемыми на нём сервисами и набор мобильных клиентов, связанных с сервером по проприетарному протоколу. Клиентымогут работать на телефонах с очень маленькими возможностями, такими какустаревшие Java-телефоны, в этом случае используется тонкий клиент, которыйтолько отображает формируемое на сервере изображение пользовательскогоинтерфейса и передаёт на сервер события нажатий на клавиши.
Для болеесовременных моделей возможна передача на клиент построенного на сервередерева визуальных элементов управления, которые отображаются на телефонесредствами его операционной системы. Возможно также написание толстого176клиента, реализующего часть бизнес-логики на телефоне. В любом случае, насервере для каждого подключённого клиента создаётся отдельный поток, в котором и работает большая часть клиентской логики программы. Этот поток можетобщаться с потоками, относящимися к серверной части сервиса, таким образомдостигается возможность взаимодействовать с серверной частью приложения идругими пользователями.
Таким образом, сообщения между сервером и клиентомфизически передаются между потоками, работающими на сервере, по каналуданных передаётся только результат обработки.С точки зрения прикладного программиста процесс создания сервиса в UbiqMobile представляет собой программирование клиентского и серверных потоковкак реализацию подклассов одного из классов платформы Ubiq Mobile. Требуетсяопределить формат сообщений, которыми обмениваются клиент и сервер (в видеC#-классов) и описать методы, реагирующие на приём сообщения на клиенте ина сервере. Также потребуется описать пользовательский интерфейс приложения,также в виде набора объектов на C# (это делается в достаточно декларативноми удобном для текстового программирования стиле). Результат должен бытьоформлен в виде C#-библиотеки, собран вместе с библиотеками Ubiq Mobile,выложен в папку с исполняемым файлом сервера Ubiq Mobile и добавлен вего конфигурационный файл.
Очевидно, что все подобные библиотеки имеютпохожую структуру, и для их создания требуется выполнение повторяющихсядействий, поэтому имеется возможность для автоматизации.Авторы платформы Ubiq Mobile выбрали DSM-платформу QReal для реализации технологии и набора визуальных языков, которые упростили бы разработкумобильных приложений под эту платформу. Целью совместной работы былосоздание на базе QReal технологии, позволявшей описывать в визуальном видетолько изменяющуюся от приложения к приложению часть и генерировать повизуальной модели проект для среды разработки Visual Studio [53], который былбы готов к сборке итоговой библиотеки, не требуя при этом ручных правок.Разработка была разделена на несколько этапов. Целью первого этапа былосоздание прототипа технологии, чтобы оценить применимость DSM-подхода кэтой задаче.
Прототип должен был генерировать логику поведения клиентскойчасти приложения, позволяющего осуществлять видеонаблюдение: веб-камера,подключённая к компьютеру, передаёт с определённой частотой кадры на сервер177Ubiq Mobile, к серверу могут подключаться мобильные клиенты, которым перенаправляются кадры с камеры. И камер, и клиентов может быть несколько в одинмомент времени, клиент может указать, с какой камеры ему необходимо получатькадры (более подробно о мотивации и задаче этого примера было рассказано вдокладе [142]).
Пользовательский интерфейс клиентского приложения на этомэтапе должен был описываться вручную. Задачи второго этапа включали в себяреализацию полноценной технологии, включающей в себя визуальное заданиепользовательского интерфейса приложения. Ниже приводится подробное описание только первого этапа, поскольку работы по второму этапу ещё не законченыи ведутся со значительно меньшим участием автора данной диссертации.A.2.3.
Визуальный язык QReal:UbiqФазы анализа применимости и анализа предметной области для данного DSMрешения состояли в консультациях с авторами технологии Ubiq Mobile, выступавшими здесь в роли экспертов предметной области и в анализе существующихисходных кодов сервисов, написанных под эту платформу. В данном случаедля выделения ключевых сущностей предметной области и создания языка былвыбран подход «от исходного кода», поскольку у авторов платформы уже имелсядостаточно большой набор работающих примеров и понимание того, что хотелосьбы автоматизировать.В результате анализа исходного кода было принято решение разработатьтри различных визуальных языка, отвечавших двум основным областям вариативности создаваемых сервисов: описание структуры сообщений, которымиобмениваются клиент и сервер, и описание логики обработки сообщений наклиенте и на сервере.
Третий визуальный язык был нужен для описания связимежду различными диаграммами первых двух языков, диаграммы на нём служиличем-то вроде заголовка визуальной модели системы.Визуальные языки QReal:Ubiq состоят из следующих сущностей.1. Мастер-диаграмма (Ubiq Master Diagram) описывает главный класс серверного приложения и является по сути связью между остальными диаграммами системы. Эта диаграмма должна содержать ровно один элементMaster Node, в котором описано, откуда сервер получает сообщения и178какие обработчики необходимо вызвать при их получении. Такая диаграммадолжна быть одна в проекте. Виды узлов на этой диаграмме таковы.(a) Constant — константа, описанная внутри класса сервера. Имеет имя,тип и значение. Может находиться только внутри Master Node.(b) Field — поле класса сервера.
Имеет имя, тип, значение по умолчанию,может быть отмечено как статическое. Может находиться тольковнутри Master Node.(c) Handler — описывает источник событий для сервера, имеет имя(которое может принимать два значения: либо OnTcpIpMessage, чтоозначает, что сервер может обрабатывать сообщения, полученныепо TCP-IP, либо OnMailBoxMessage, что означает, что сервер можетобрабатывать сообщения от другого процесса). Может находитьсятолько внутри Master Node. Каждый такой узел должен быть связанс помощью провязки с диаграммой активностей, описывающей поведение соответствующего обработчика.(d) Master Diagram — корневой узел диаграммы, все остальные узлыдолжны быть вложены в него.(e) Master Node — описание класса серверной части приложения.
Можетсодержать в себе описания обработчиков событий, констант, полей,препроцессоров (узлы Handler, Constant, Field, Preprocessor), имеетсвойства «имя» (имя класса сервера), initCode (произвольный кодна C#, генерирующийся в конструктор класса), onTcpIpCloseHandler(произвольный код на C#, выполняющийся при закрытии TCP-IPсоединения). Может быть связан провязкой с диаграммами активностей, описывающими реализацию вспомогательных функций, которыесгенерируются как методы этого класса.(f) MasterDiagramComment — комментарий.(g) Preprocessor — метод, вызываемый перед передачей сообщения обработчику, предназначенный для преобразования сообщения перед передачей обработчику.