Full Text

Введение. На сегодняшний день существует огромное количество языков программирования, а также множество подходов и методов для написания программ. Отличие современных методов разработки программных систем от тех, которые были созданы несколько десятилетий назад, заключается в разработке программных средств в комплексе, т.е. помимо организации программного кода рассматриваются также его защита, документирование, использование сторонних сервисов для контроля версий, тестирование и т.д. Различные методы, используемые для разработки сложного программного обеспечения, применяются для различных конечных целей и для определенного набора ресурсов. Программные продукты, разрабатываемые в настоящее время, представляют собой сложные и высоконагруженные системы, затрагивающие различные предметные области. На ранних стадиях разработки ПО, в частности, при формировании концепции приложения, часто возникают проблемы, связанные со сложностью восприятия экспертами языков, используемых для моделирования предметной области, что тормозит процесс разработки. Также бывает сложно объяснить понятия, которыми оперируют пользователи информационной системы, с помощью языков общего назначения. Поэтому растет популярность предметно-ориентированных языков программирования (DSL), предназначенных для определенного спектра задач в рамках конкретной предметной области [1]. Предметно-ориентированные языки понятны определенным категориям специалистов, так как они оперируют терминами близкой для них предметной области [2]. Тренажер виртуальной реальности представляет собой аппаратно-программный комплекс, состоящий из очков виртуальной реальности, надетых на голову пользователя, в которые вставлен смартфон, демонстрирующий главное окно программы, устройства Kinect, предназначенного для отслеживания движений пользователя в пространстве, и программы, содержащей различные сборки деталей, которые и предлагается собрать пользователю. Главное окно программы представляет собой набор отдельных деталей, находящихся на определенном расстоянии друг от друга. Двигая руками, пользователь может брать детали и производить над ними определенные операции (закручивание, вставка), тем самым собирая единую деталь. После окончания сборки пользователь может посмотреть статистику, показывающую, за какое время была собрана деталь, какое количество ошибок было совершено, а также сравнить свои результаты с результатами других пользователей тренажера или со своими результатами, полученными ранее. Архитектура программной части тренажера представлена на рис. 1. Модуль размещения деталей на сцене Тренажер виртуальной реальности Модуль анализа результатов сборки Модуль обработки движений пользователя Модуль конвертирования деталей из формата m3d в STL Рис. 1. Архитектура тренажера виртуальной реальности Рассмотрим модуль конвертирования деталей из формата m3d в формат STL. Детали и сборки в тренажер загружаются из программы «КОМПАС 3D», где изначально создаются. Однако данная программа имеет закрытый файловый формат (m3d), что не позволяет в дальнейшем работать с деталями, созданными в этой программе, в других средах. Для решения этой проблемы был разработан модуль, который представляет собой конвертер, позволяющий переводить детали из данного формата в открытый и часто используемый для хранения 3D-моделей формат STL. Формат STL был выбран потому, что время генерации такого файла относительно мало и он имеет простую структуру. Контекстная диаграмма процесса конвертирования изображена на рис. 2. Конвертирование Нормативные документы Программная документация ЕСКД Компас 3D Модели в формате STL Файлы в формате m3d и a3d Программный модуль Технолог Рис. 2. IDEF0-диаграмма процесса конвертирования В качестве основной методики для реализации модуля был выбран подход языково-ориентированного программирования (ЯОП). ЯОП представляет собой парадигму программирования, смысл которой состоит в том, что процесс разработки программного обеспечения делится на стадии разработки предметно-ориентированных языков и описания решения задачи с использованием этих языков [3]. Язык DSL представляет собой язык программирования, который применим только для конкретной области. Построение такого языка отражает специфику решаемых с его помощью задач. Актуальность использования DSL на сегодняшний день подтверждается многими известными программными продуктами, использующими или включающими такие языки (Oracle, AutoCAD, Microsoft Office и др.) [4]. Удобство применения DSL также отмечается и на ранних стадиях разработки крупного ПО, когда для проектирования архитектуры ПО разработчикам необходимо понять все тонкости предметной области, которые им могут рассказать эксперты. В итоге получившаяся схема будет понятна как экспертам, поскольку будет содержать понятные им слова, так и разработчикам, так как им будет ясна дальнейшая архитектура приложения. Предметно-ориентированные языки также можно использовать для создания программ для автоматизированного тестирования [5], для рисования блок-схем на основе псевдокода, который создается автоматически при добавлении элементов на лист [6], также для описания документов, которые используются при проектировании информационных систем [7]. Однако язык DSL не является универсальным, а имеет конкретную специфику. Зачастую при разработке синтаксического дерева языка могут возникнуть трудности с созданием зарезервированных слов или с иерархией понятий, поэтому рекомендуется сначала построить онтологию предметной области, затем на ее основании, соблюдая иерархию, выделять слова, наиболее четко характеризующие содержимое каждого класса [8]. В качестве примера можно рассматривать средство для разработки мобильных приложений Ubiq Mobile [9], которое позволяет создавать приложения, используя набор специализированных графических языков, ориентированных на разные предметные области. Это, с одной стороны, понижает сложность разработки, с другой - расширяет области использования мобильных устройств. В некоторых источниках [10] были выделены шаги, которые выполняются при разработке DSL, а также описана архитектура построения конечного программного кода. Не исключено, что язык DSL может использоваться в программах, использующих другой подход - объектно-ориентированный [11], однако рекомендуется придерживаться какого-либо одного подхода, чтобы не было путаницы в структуре программы. Таким образом, средства на основе DSL используются для создания различных программных приложений, в том числе и мобильных. Продукты, содержащие в себе множество DSL для разных сфер, облегчают разработку сложных программных систем. Разработка предметно-ориентированного языка для модуля тренажера виртуальной реальности. Предметно-ориентированный язык для модуля конвертирования деталей должен описывать детали в формате САПР «КОМПАС 3D», детали в формате STL и шаги процесса конвертирования (см. рис. 2). Для описания деталей из формата «КОМПАС 3D» было принято решение выделять основные характеристики, а именно: наименование, цвет, позицию в локальных координатах сцены, длину, ширину и высоту. Для описания деталей в формате STL использовались: имя, координаты вершин треугольников, на которые разбивается модель при сохранении, координаты нормалей треугольников. Сам процесс конвертирования является достаточно простой процедурой, поэтому нет смысла его разбивать на шаги, а достаточно просто описать в отдельной функции. Зарезервированные слова получились соответственно следующие: KompasFormat (деталь в формате «КОМПАС 3D»), STLFormat (деталь в формате STL) и Convert для обозначения процесса конвертирования. Поскольку весь DSL небольшой и не прослеживается явного наследования между компонентами, то строить иерархическую модель языка не требуется. После разработки синтаксиса языка его необходимо перенести в среду разработки. Для реализации DSL была выбрана среда разработки Visual Studio 2015 Community. Так как по умолчанию средств для работы с DSL там нет, то необходимо дополнительно установить Visual Studio SDK и Visual Studio Visualization And Modeling SDK. Данные пакеты содержат необходимые средства для разработки компонентов под саму среду Visual Studio и ЯОП [12]. В Visual Studio процесс создания языка представлен в виде диаграмм, похожих на нотацию UML. Также существуют классы и различные связи между ними. После создания диаграммы на ее основе автоматически генерируется код, который впоследствии можно внедрить в проект и пользоваться уже непосредственно словами DSL, предварительно описав в коде класса и связях, что конкретно они будут делать [13]. При создании проекта DSL автоматически создастся тестовая диаграмма, демонстрирующая возможности языка (рис. 3). После удаления ненужных классов и связей необходимо создать свою диаграмму, описывающую язык [14]. Вначале для удобства будет стоять главный абстрактный класс, характеризующий любую деталь, он создается автоматически по умолчанию, и его нельзя удалить. Данный класс по определению не будет иметь полей [15]. Далее от него наследуется класс KompasFormat, описанный выше со всеми необходимыми полями. Класс KompasFormat будет связан с классом STLFormat связью Convert. Такая небольшая диаграмма будет удовлетворять нашим требованиям. При создании более сложного языка DSL следует обращать внимание на тип связей между классами, правильно его определить поможет диаграмма, отражающая иерархию связей между синтаксисом языка (рис. 4). Рис. 3. Начальная диаграмма при создании проекта DSL в Visual Studio Рис. 4. Диаграмма языка DSL На основе разработанной диаграммы языка необходимо получить программный код для того, чтобы зарезервированные слова в дальнейшем можно было использовать в модуле конвертации. Для генерации кода использована технология Т4, предоставляющая все необходимые инструменты для создания кода с помощью шаблонов. Данная технология позволяет генерировать программный код на языках C#, VB.Net, а также SQL-запросы, HTML-коды и множество других видов текстовой информации [16]. Файлы, являющиеся результатом работы Т4, будут иметь расширение *.tt, и именно в них и будут находиться необходимые коды для дальнейшего внедрения в модуль (рис. 5). После генерации необходимых файлов следует дополнить код классов указанием, какие именно действия необходимо производить при вызове того или иного зарезервированного слова [17]. Например, при вызове KompasFormat нужно считывать параметры детали, указанные в полях данного класса и сохранять их в отдельный файл, при вызове Convert находить файл, который был создан при вызове KompasFormat, брать из него необходимые данные и создавать новый файл с параметрами, необходимыми для сборки STL-файла. Рис. 5. Сгенерированные классы Написав все необходимые инструкции, можно начинать внедрение DSL в модуль конвертации. Внедрение подразумевает перенос всех сгенерированных файлов в проект, создание ссылок на них и затем дальнейшее использование. Получившаяся архитектура модуля конвертации представлена на рис. 6. Деталь в формате m3d Деталь в формате STL DSL для конвертации Рис. 6. Архитектура модуля конвертации Модуль конвертации можно было также реализовать, используя объектно-ориентированный подход. В этом случае нужно было бы написать программу для формата сохранения деталей программой «КОМПАС 3D», создать классы, описывающие детали, сборки, записи данных в файлы. Архитектура модуля представлена на рис. 7. Деталь в формате m3d Деталь в формате STL Парсер формата m3d Формирование файла STL Рис. 7. Архитектура модуля при применении объектно-ориентированного подхода При сравнении предметно-ориентированного и объектно-ориентированного подходов в каждом можно выделить свои плюсы и минусы. Например, для высоконагруженной системы с большими объемами данных и сложной архитектурой лучше использовать объектно-ориентированный подход, для небольшой, прозрачно контролируемой и гибкой системы лучше использовать DSL [18]. Также можно отметить, что DSL на стадии проектирования использовать лучше, так как при разработке решения на основе терминов предметной области в нем может разобраться и человек, не являющийся программистом, однако хорошо понимающий данную сферу. При выборе подхода для разработки необходимо руководствоваться не только целями и задачами приложения, но и его дальнейшим развитием, а также предпочтениями участников команды разработки (таблица). Например, подход на основе DSL позволит легко добавить новые форматы представления деталей в модуль конвертации за счет небольшого изменения DSL. При использовании ООП потребуется переписывать алгоритмы, позволяющие выполнить преобразования из одного формата в другой. Сравнение предметно-ориентированного и объектно-ориентированного подходов Критерии сравнения Предметно-ориентированный подход Объектно-ориентированный подход Большая прозрачность и понятность на этапе проектирования + - Гибкость в расширении и минимум репликации кода + - Удобство моделирования компонентов приложения между собой - + Лаконичность написания кода + - Возможность быстрого добавления других форматов представления деталей + - Таким образом, для реализации задачи, описанной в данной работе, лучше использовать метод DSL. Выводы. Предметно-ориентированный подход позволяет организовать внутренний механизм работы программы таким образом, чтобы он был понятным и хорошо контролируемым. На примере работы модуля конвертации данный подход был продемонстрирован и показал хорошие результаты, немного уступая объектно-ориентированному подходу в производительности из-за большого объема сгенерированного кода. Следует отметить, что сейчас часто практикуется метод генерации кода по схемам. Например, если имеется диаграмма классов, то для того, чтобы не тратить время на написание самих классов, среда программирования автоматически генерирует необходимую оболочку, а разработчику остается лишь добавить функционал [19]. Данные генераторы в средах, разработанных компанией Microsoft, используют ту же самую технологию Т4, описанную выше, а для интерпретирования схем в код используется DSL, описывающий различные диаграммы [20]. Это свидетельствует о том, что данный подход совершенствуется и в дальнейшем, возможно, появятся системы, способные полностью взять на себя задачу кодирования, а разработчикам придется лишь составлять и проектировать визуальные модели.

About the authors

O. L Vikenteva

National Research University «Higher School of Economics»

D. A Selukov

Perm National Research Polytechnic University

References

Statistics

Views

Abstract - 63

PDF (Russian) - 33

Refbacks

• There are currently no refbacks.