- •Введение
- •1 Анализ предметной области
- •1.1 Постановка задачи
- •1.2 Обзор аналогов
- •2 Программная документация
- •2.1 Техническое задание на программное обеспечение
- •2.1.1 Назначение разработки
- •2.1.2 Терминология
- •2.1.3 Требования к функциональным характеристикам
- •2.1.4 Требования к надежности
- •2.1.5 Требования к составу и параметрам технических средств
- •2.1.6 Требования к информационной и программной совместимости
- •2.1.7 Требования к результатам работы
- •2.1.7.1 Требования к комплектации решения
- •2.1.7.2 Требования к документации
- •2.1.8 Перечень работ по этапам
- •2.2 Пояснительная записка
- •2.2.1 Назначение и область применения
- •2.2.2 Описание разработанной технологии создания программ для распределенных микроконтроллерных систем
- •2.2.2.1 Схема оборудования
- •2.2.2.2 Недостатки диаграммы Бара для проектирования микроконтроллерных программ управления
- •2.2.2.3 Концепции диаграммы задач
- •2.2.2.4 Семантика отображаемых на диаграмме задач связей
- •2.2.2.5 Синхронные и асинхронные вызовы функций задач
- •2.2.2.6 Синхронный вызов функции пакета
- •2.2.2.7 События и подписки
- •2.2.2.8 Текстовый язык
- •2.2.2 Технические характеристики
- •2.2.2.1 Описание структуры программной системы
- •2.2.2.1.1 Платформа разработки
- •2.2.2.1.2 Подсистема редактирования
- •2.2.2.1.3 Разработка графических редакторов
- •2.2.2.1.4 Разработка текстового редактора
- •2.2.2.1.5 Описание языка
- •2.2.2.1.6 Семантический анализ пользовательской программы
- •2.2.2.1.7 Генерация кода на целевом языке
- •2.2.2.1.8 Генерация кода редактора текстового языка
- •2.2.2.1.9 Проектирование отладчика
- •2.2.2.1.10 Регистрация конфигурации запуска
- •2.2.2.1.11 Модель отладки
- •2.2.2.1.12 Виртуальная машина
- •2.2.2.1.13 Моделирование
- •2.2.2.1.14 Концепция параметризированных сигналов
- •2.2.2.1.15 Функциональное моделирование блоков устройств
- •2.2.3 Ожидаемые технико-экономические показатели
- •2.3 Описание программы
- •2.3.1 Описание логической структуры
- •2.3.1.2 Типичный поток событий в графическом редакторе
- •2.3.2 Входные и выходные данные
- •2.3.3 Используемые технические средства
- •2.4 Программа и методика испытаний
- •2.4.1 Программа испытаний
- •2.4.2 Методика испытаний
- •3 Руководство пользователя
- •3.2 Условия выполнения программного комплекса
- •3.3 Установка программы
- •3.4 Текстовый редактор
- •3.5 Графический редактор
- •4 Акт испытаний программного продукта
- •5 Экономическая часть
- •Заключение
- •Список использованных источников
2.3.1.2 Типичный поток событий в графическом редакторе
Рассмотрим описание потока событий в графическом редакторе на примере запроса пользователя на добавление функции в задачу.
Соответствующая диаграмма последовательности приведена в приложении В на рисунке В.2. Как видно из диаграммы, для того, что пользователь имел возможность выполнить команду, она должна быть выполняемой для текущего контекста. Контекст определяет действие AddMethodAction, в данной ситуации в качестве контекста AddMethodAction использует выделенный объект. Если выделенный объект является задачей (выделенными объектами в GEF являются контролеры), то команда считается выполнимой. Когда пользователь решает исполнить команду, у действия вызывается метод run. Задача действия – получить команду от контролера, в связи с чем он и делегирует ему эту задачу, а контролер в свою очередь обращается к специально разработанной для этого случая политике FlowLayoutEditPolicy, которая непосредственно создает команду (ShapeCreateCommand) по добавлению функции к задаче. Суть этой команды заключается в добавлении единожды созданной функции к задаче или удалении ее (при выполнении команды redo). Добавление функции к задаче происходит на уровне модели графического редактора, при этом согласно архитектуре GEF и структуре разработанного редактора, происходит уведомление контролера задачи о добавлении нового элемента в модель. Контролер сам сообщает библиотеке GEF о произошедших изменениях. GEF далее вызывает метод getModelChildren, чтобы узнать элементы модели, для которых нужно создать контролеры, которые будут агрегироваться в контролер задачи. При этом для создания фигур созданных контролеров функций GEF обращается к их методам createFigure. Фигура, возвращаемая из createFigure контролера функции будет добавлена на холст к фигуре задачи.
2.3.1.3 Реализация текстового редактора
Согласно выбранной технология разработки текстового редактора (Xtext) была разработана его грамматика, приведенная в приложении Б. Разработка грамматики на языке Xtext производилась на основе грамматики языка С стандарта ANSI C 1995 года грамматики 2006 года для инструмента ANTLR, которая в свою очередь была основана на грамматике С для инструмента Yacc [51] 1985 года. В грамматику были добавлены дополнительные конструкции, сама форма грамматики была адаптирована под нотацию Xtext.
Также были разработаны следующие компоненты, интегрируемые со сгенерированным Xtext текстовым редактором через технологию встраивания зависимостей Google Guice:
- модуль предоставление областей видимости для процесса линковки;
- модуль валидации для проверки корректности типов, использующий компонент TypeSystem;
- модуль предоставления названий (LabelProvider) для отображения названий элементов синтаксического дерева в окне отображения структуры документа.
2.3.2 Входные и выходные данные
Входными данными для текстового редактора является текстовый файл с расширением *.mydsl c программой. В ходе разбора программы на выходе получаем AST дерево на базе модели EMF. Преимуществом использования технологии EMF для представления моделей текстового и графического языков в системе является возможность унифицированного внутреннего представления одной и той же модели (семантической модели) вне зависимости от графического или текстового редактора, что обеспечивает возможность как прямого генерирования модели по диаграмме задач, так и проведения обратного восстановления диаграммы задач по коду.
В результате генерации кода на язык С генератором по AST-дереву от парсера получаем файл на языке С, который подается на вход компилятору gcc, в результате чего пользователь получает образ программы, который можно с помощью сторонних специализированных программ зашивать в микроконтроллер.
В результате генерации кода на язык Lua получаем программу для виртуальной машины, управление работы которой занимается отладчик. Программа на языке Lua предусматривает обращение к классам моделей автоматизирующих и автоматизируемых устройств (на языке Java), которые, в свою очередь, приводят к анимации на схеме оборудования и диаграмме задач.