Задача на протяжении десятилетий заключалась в том, чтобы найти повторяемый, предсказуемый процесс или методологию, которая повысит производительность, качество и надежность разработки.
Некоторые пытались систематизировать и формализовать этот, казалось бы, непредсказуемый процесс.
Другие применяли к этому методы управления проектами и разработки программного обеспечения.
Третьи считали, что без постоянного контроля со стороны заказчика разработка программного обеспечения выходит из-под контроля, что влечет за собой увеличение временных и финансовых затрат. Информатика как научная дисциплина предлагает и использует на основе методов структурного программирования технологии надежной разработки программного обеспечения, используя тестирование и верификацию программ на основе доказательных методов программирования для систематического анализа корректности алгоритмов и разработки программ без алгоритмических ошибок.
.
Эта методика направлена на решение задач на МВМ, аналогичная технологии разработки алгоритмов и программ, используемой на олимпиадах по программированию отечественными студентами и программистами, использующими тестирование и структурный псевдокод для документирования программ в корпорации IBM с 70-х годов.
Методологию структурированного проектирования программного обеспечения можно использовать с использованием различных языков и инструментов программирования для разработки надежных программ любого назначения.
Однако при использовании классического подхода к разработке возникают проблемы, описанные под хаком:
- Отсутствие прозрачности.
В любой момент времени сложно сказать, в каком состоянии находится проект и каков процент его завершения.
Данная проблема возникает при недостаточном планировании структуры (или архитектуры) будущего программного продукта, что чаще всего является следствием отсутствия достаточного финансирования проекта или низкой квалификации разработчиков.
- Недостаток контроля.
Без точной оценки процесса разработки срываются графики работ и превышаются установленные бюджеты.
Трудно оценить объем выполненных и оставшихся работ. Данная проблема возникает на этапе, когда проект, завершенный более чем наполовину, продолжает развиваться после дополнительного финансирования без оценки степени завершенности проекта.
- Отсутствие мониторинга.
Проблемы, связанные с невозможностью следить за ходом реализации проекта, не позволяют отслеживать ход разработки в режиме реального времени.
Используя инструменты, менеджеры проектов принимают решения на основе данных в реальном времени.
Данная проблема возникает в условиях, когда стоимость обучения менеджмента освоению инструментов сравнима со стоимостью разработки самой программы.
- Неконтролируемые изменения.
У заказчика постоянно возникают новые идеи относительно разрабатываемого программного обеспечения.
Влияние изменений может сильно изменить архитектуру разрабатываемого проекта, поэтому важно оценивать предлагаемые изменения и внедрять только одобренные, контролируя этот процесс с помощью программных средств.
Данная проблема возникает из-за нежелания конечного потребителя использовать определенные программные среды.
Например, при создании клиент-серверной системы потребитель предъявляет требования не только к операционной системе на клиентских компьютерах, но и к компьютеру-серверу.
- Недостаточная надежность.
Самый сложный процесс — поиск и исправление ошибок в программах на ВМ.
Поскольку количество ошибок в программах заранее неизвестно, продолжительность отладки программ также заранее неизвестна и нет никакой гарантии отсутствия ошибок в программах.
Следует отметить, что использование доказательного подхода к проектированию программного обеспечения позволяет обнаружить ошибки в программе еще до ее выполнения.
Профессор Вирт при разработке Паскаля и Оберона благодаря строгости их синтаксиса добился математической доказуемости полноты и корректности программ, написанных на этих языках.
Дональд Кнут внес особенно важный вклад в дисциплину программирования.
Его четырехтомник «Искусство программирования» обязателен к прочтению каждому серьезному программисту.
- Отсутствие гарантий качества и надежности программ из-за невозможности обеспечить отсутствие ошибок в программных продуктах вплоть до официальной поставки программ заказчикам.
- Систематическое повторное использование.
Наиболее важным подходом является выявление семейств продуктов, составляющие которых различаются.
Линии продуктов разрабатываются на основе этих семейств.
Продукты, разработанные как компоненты семейств, повторно используют требования, архитектуру, платформы, компоненты, текст и т. д.
- Автоматизация сборки.
Облегчает сборку самостоятельно разработанных компонентов.
При автоматизации сборки появляется ряд новшеств:
- платформенно-независимые протоколы;
- автоматическое описание (уменьшает архитектурные несоответствия на основе контракта и спецификации);
- отложенная инкапсуляция (уменьшает архитектурные несоответствия за счет встраивания адаптаций в опубликованные компоненты);
- архитектурно-ориентированная разработка (на основе архитектуры программного обеспечения могут быть сделаны предложения по его производительности).
- Разработка на основе моделей (MDD).
Этот подход предполагает использование модели в качестве исходного кода, а не документации.
Для этого модель должна быть точной, а точный язык моделирования должен быть разработан для конкретной цели.
Язык моделирования — это система, созданная для спецификации программ, основанных на моделях.
Это повышает уровень абстракции и переводит реализацию в словарь предметной области.
Интерфейс прикладного программирования (API) — это группа системных сервисов, ориентированных на решение общих задач.
Компонентные технологии представляют собой набор программных модулей со стандартизированным интерфейсом, направленных на решение типовых задач.
Архитектурные шаблоны — это проектные решения, описывающие архитектуру программной системы, основанную на определенной концепции.
Шаблоны GoF — это проектные решения, описывающие аспекты реализации программной системы для решения конкретных задач программирования.
Языки на основе XML обеспечивают структурированное описание определенных данных и механизмов преобразования.
SQL — это язык структурированных запросов для СУБД.
Онтология — это представление какой-либо области знаний или части реального мира, которое используется для семантического анализа текстов.
Язык, специфичный для предметной области (DSL), моделирует концепции, определенные в конкретной предметной области.
Хорошо спроектированный DSL — это мощный язык моделирования, имеющий более высокую степень однозначности, чем язык моделирования общего назначения.
DSL — это язык программирования, специально разработанный для решения определенного круга задач, в отличие от языков программирования общего назначения.
Существует три основных типа DSL:
- внутренний DSL (внутренний DSL);
- внешний DSL — DSL, написанный на языке, отличном от основного языка программного приложения;
- интегрированная среда разработки DSL (Language Workbench).
Внешний DSL использует конструкции, отдельные от основного синтаксиса, близкие к естественному языку.
Требует внешнего компилятора, интерпретатора или постпроцессора и поэтому выполняется на этапе компиляции, в отличие от внутреннего DSL. Внешний DSL часто использует специализированные языки, но во многих распространенных случаях в качестве общей альтернативы используются теги, взятые из синтаксиса других языков, таких как XML. Традиционно системы Unix используют стиль «маленьких языков».
Одними из самых ранних примеров внешнего DSL были регулярные выражения, SQL, awk и XML, которые использовались в таких системах, как Struts и Hibernate. Самым большим преимуществом внешних DSL является то, что их можно писать по желанию разработчика.
Другими словами, вы можете выразить предметную область в максимально простой форме, удобной для чтения и редактирования.
Формат такого DSL будет ограничен лишь возможностью создания транслятора, способного читать файл конфигурации и генерировать некоторый исполняемый код на основном языке приложения.
Отсюда же вытекает и основной недостаток внешних DSL — необходимость создания транслятора напрямую.
Внутренний DSL использует некоторые синтаксические конструкции общего языка программирования для выражения на языке, близком к естественному, определенных аспектов приложения.
Для выполнения не требуется сторонний компилятор; он выполняется, когда основной код программы выполняется на общем языке программирования.
Внутренний DSL используется некоторыми распространенными языками программирования для расширения возможностей программ, но он создает существенно ограниченное подмножество конструкций для управления программой.
Классическими примерами использования внутренних DSL являются Lisp и Ruby. Интегрированная среда разработки (IDE) — это инструмент для создания DSL. Он предоставляет возможности редактора и генератора для определения абстрактного синтаксиса языка, аналогично современным IDE для разработки программ.
В целом DSL, дополненные технологией метапрограммирования, являются эффективным средством автоматизации разработки программного обеспечения и в настоящее время широко используются в информационных технологиях.
Общий алгоритм разработки нового DSL следующий: 1 Определите синтаксис с точки зрения языка реализации 2. Используйте шаблоны DSL для реализации нового DSL. 3. Используйте инструменты метапрограммирования для реализации DSL в исходном языке.
Использование DSL также имеет ряд преимуществ:
- на этапе проектирования дает возможность создавать решения в рамках предметной области, благодаря чему специалисты в заданной предметной области могут создавать и модифицировать DSL-программы.
- при проектировании в схожей предметной области можно использовать готовый DSL;
- решение предметной задачи с использованием DSL происходит на соответствующем уровне абстракции.
Это позволяет экспертам в предметной области понимать и проверять программы DSL;
- программы, написанные с использованием DSL, кратки.
Написание DSL с использованием доменных терминов позволяет довольно легко читать программу в будущем;
- происходит повышение надежности, эффективности и качества поддержки.
Поскольку операции на уровне модели выполнять легче, они более эффективны и подвержены меньшему количеству ошибок, чем те же операции на уровне кода;
- DSL позволяет выполнять оптимизацию и проверку на уровне абстракции, соответствующем предметной области;
- описание предметной области на одном уровне абстракции затем может быть переведено на более низкий уровень детализации.
Таким образом, вы сможете дополнять модель на разных этапах разработки.
- стоимость проектирования, внедрения и обслуживания достаточно высока;
- необходимость обучения пользователей;
- Область применения DSL определить довольно сложно;
- сложность поддержания баланса между конструкциями, используемыми в DSL, и конструкциями языка программирования общего назначения.
Спасибо тем, кто дочитал до конца, хотелось бы услышать ваше мнение о проблемах дизайна вообще и языках описания предметных областей в частности, как об одном из вариантов решения возникающих трудностей.
Теги: #dsl #внутренний DSL #внешний DSL #кодирование #дизайн #языковая среда #разработка веб-сайтов
-
Принципы Шифрования
19 Oct, 24 -
Опыт Обновления Xp До Windows7
19 Oct, 24 -
Щелчок В Суставе
19 Oct, 24 -
Новости Openstreetmap №5
19 Oct, 24 -
Aquanotus - Водяные Знаки Онлайн
19 Oct, 24
