Диссертация (1090660), страница 7
Текст из файла (страница 7)
Именно такое сочетание возникает при работе на уровне фреймворков, рассмотренных ранее. Специализированный интерфейс программирования приложений API (англ. Application ProgrammingInterface) также содержит в себе предметно-ориентированный набор классов, методови функций, доступных путём построения различных объектов и вызовов соответствующих методов из любого языка общего назначения, задействовав необходимую библиотеку для работы с таким API. Чем же обусловлена целесообразность разработкипредметно-ориентированного языка? Тем, что они решают задачи своей предметнойобласти лучше, поскольку полностью под неё заточены [66].
Следующие особенностихарактерны для предметно-ориентированных языков:– Чётко заданные сущности супротив пользовательским операторам, задаваемымв языках общего назначения. Эту особенность не стоит недооценивать, т.к. онанапрямую влияет на продуктивность использования DSL.– Специфичные конструкции и абстракции не всегда могут быть представленыочевидным образом и помещены в библиотеку или фреймворк на языке общегоназначения. Типичный случай — обработка ошибок [6, 8, 20]. Языки общегоназначения могут выразить эти конструкции косвенным, неявным образом. DSLпредоставляет такие конструкции изначально.32– Использование предметно-ориентированных языков предоставляет возможностианализа, проверки, оптимизации, параллелизма и транформации в понятиях своей предметной области.
Достижение аналогичных свойств на GPL трудоёмкоили недостижимо вовсе, поскольку шаблоны проектирования, задействованныев языках общего назначения, достаточно сложны и, как правило, недостаточновыразительно описаны.Несмотря на свои недостатки, фреймворки и прикладные библиотеки являютсясерьёзными конкурентами предметно-ориентированных языков. Справедливым будетсказать, что большинство DSL никогда не смогут превзойти уровень фреймворков.Большинство описанных выше достоинств предметно-ориентированных языков недостигается легко, существуют и свои подводные камни, влекущие значительные трудовые затраты:– Разработка DSL усложняется тем, что требует специальной экспертизы предметной области и знания принципов разработки языков программирования.– В отличие от GPL, техники разработки DSL могут сильно видоизменяться, требуя тщательного рассмотрения всех нюансов.– В случае слабой поддержки сообщества пользователей языка, могут возникнутьсерьёзные проблемы с разработкой учебного материала, стандартизацией и сопровождением.Фундаментальные понятия, лежащие в основе соответствующего предметноориентированного языка, могут быть сформированы только после многолетнего опыта использования языков общего назначения для решения задач рассматриваемойпредметной области.
В таком случае, как указывают авторы работы [4], новый языкможет стать ключевым шагом в развитии программной инженерии и эволюции программного обеспечения.1.3.2Требования к стадии принятия решенияРазработка предметно-ориентированного языка проходит в несколько стадий, среди которых: принятие решения, анализ, проектирование, реализация и внедрение. Темне менее, как показывает практика, разработка DSL не является последовательнымпроцессом. На стадию рассмотрения может влиять стадия анализа, которая, в свою33очередь, может дать ответы на неочевидные вопросы, возникающие во время проектирования. К стадии проектирования зачастую снова обращаются на стадии реализации.Каждой стадии (кроме развёртывания) соответствует определённый набор подходов.
Стадия принятия решения отвечает на вопрос «зачем?» по отношению к разработке DSL, а все остальные – отвечают на вопрос «как?» [44]. Подходы для принятиярешения — это набор типовых ситуаций, составленный на опыте уже разработанныхи успешно функционирующих предметно-ориентированных языков. Эти характеристики относятся к стадии принятия решения, где даётся ответ о целесообразностиразработки нового DSL. Точно также, аналитические подходы, подходы проектирования и подходы реализации описывают общие подходы для, соответственно, анализапредметной области, проектирования DSL и его реализации.Количественныйанализцелесообразностиразработкиновогопредметно-ориентированного языка достаточно сложен. И тем не менее, на практике, недальновидная стратегия и недостаток экспертизы на стадии принятия решения может вызвать множество неясностей и противоречий, выливающихся в нескончаемый потоквопросов о целесообразности нового DSL.
Очевидно, что адаптация уже существующего DSL менее затратна, нежели разработка нового. Для упрощения принятия решения, предлагается ряд характеристик, представленных в таблице 1.1.Представленные характеристики имеют общие задачи:– Улучшение эффективности разработки программ, способствование к повторномуиспользованию кода [74];– Предоставление пользователям без специализированных знаний программирования возможности разработки программ в необходимой предметной области [7].Рассмотрим каждый из представленных подходов более подробно. Форма представления.
Наличие подходящих (новых или уже существующих) предметноориентированных форм представления является решающим фактором при принятиирешения о разработке языка. Две важных подхарактеристики:– Преобразование визуальной в текстовую форму представления. Это преобразование даёт массу преимуществ, например, облегчённое представление большихпрограмм или спецификаций [75].– Добавляет удобную для пользователя форму представления к уже существующему API или даже преобразовывает API в DSL.34Таблица 1.1.
Предпосылки принятия решенияХарактеристикаФорма представленияОписаниеДобавляет новую или уже существующую формупредставления в предметную область. Важные подхарактеристики:– Преобразовывает визуальную форму представления в текстовую.– Добавляет удобную для пользователя формупредставления к уже существующему API.Автоматизация задачПродуктоваялинейкаПредставлениеструктур данныхОбходструктурданныхВзаимодействиеПостроение GUIЛиквидирует повторяющиеся задачиОтносится к участникам одной продуктовой линейкиСпособствует выразительному описанию данныхСпособствует выполнению сложных обходовДелает компоненты пользовательского взаимодействия программируемымиРеализует построение графических интерфейсовпользователя (GUI — (англ.
Graphical User Interface))35Автоматизация задач. Программисты, пользующиеся языками общего назначения, зачастую тратят время на решение рутинных задач, использующих общие частив тексте программы. Однако, необходимый программный код может быть сгенерирован автоматически генератором приложения (компилятором) для подходящего DSL.Продуктовая линейка. Члены единой продуктовой линейки программ выпускаютв свет единую архитектуру, содержащую общий набор базовых элементов. Использование DSL может способствовать их унификации. Эта характеристика пересекается савтоматизацией задач.Представление структур данных. Программирование, управляемое данными (англ. data-driven programming) [57], может содержать весьма сложные структуры, которые тяжело реализовывать и сопровождать.
Такие структуры зачастую проще выразить используя DSL.Обход структур данных. Обход сложных структур данных зачастую выражаетсялучше и более надёжно на DSL.Взаимодействие. Взаимодействие с прикладным программным обеспечением, основанное на наборе текста или работе с меню часто дополняется введением необходимого DSL для обработки сложного или повторяющегося ввода. К примеру, в редакторетаблиц Excel реализован собственный язык макросов, делающий Excel программируемым.Построение GUI.
Зачастую решается гораздо лучше с использованием DSL.1.3.3Требования к стадии анализаНа стадии анализа проблемная область DSL уже определена, а все необходимыезнания о ней собраны и структурированы. Входными данными для новой стадии являются: техническая документация, мнение экспертов предметной области, уже существующий исходный код на языке общего назначения, опросы потенциальных потребителей. Выходные данные варьируются, но в основном состоят из специфичнойтерминологии предметной области и семантики в более или менее абстрактной форме.В таблице 1.2 представлены модели, характерные для стадии анализа.
В большинстве случаев анализ предметной области происходит неформальным образом, ноиногда применяются различные формализованные методологии: DARE, DSSA, FAST,FODA, ODE, ODM.36Таблица 1.2. Аналитические подходыПодходНеформальныйФормальныйИзвлечение из исходного кодаОписаниеПредметная область анализируется неформальнымиметодами.Предметная область анализируется с привлечениемметодологии.Предметная область анализируется путём детальногоразбора уже существующего кода на GPL или путёмиспользования программных инструментов, или же сиспользованием обеих методик.Выходными данными формального анализа предметной области является предметная модель (англ. domain model), содержащая:– Определение предметной области и её границ;– Терминологию предметной области (словарь, онтологию);– Описание принципов предметной области;– Особенности модели, описывающие вариативные и общие свойства, а также ихвзаимосвязи.Вариативные свойства точно указывают, какая информация требуется для описания сущности системы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
