Инженерия домена — это весь процесс повторного использования знаний домена при производстве новых программных систем. Это ключевая концепция в систематическом повторном использовании программного обеспечения и проектировании линейки продуктов . Ключевой идеей в систематическом повторном использовании программного обеспечения является домен . Большинство организаций работают только в нескольких доменах. Они многократно создают похожие системы в пределах заданного домена с вариациями для удовлетворения различных потребностей клиентов. Вместо того чтобы создавать каждый новый вариант системы с нуля, можно добиться значительной экономии за счет повторного использования частей предыдущих систем в домене для создания новых.
Процесс идентификации доменов, их ограничения и обнаружения общностей и различий между системами в домене называется анализом домена . Эта информация фиксируется в моделях, которые используются на этапе внедрения домена для создания артефактов, таких как повторно используемые компоненты, доменно-специфический язык или генераторы приложений, которые могут использоваться для создания новых систем в домене.
В проектировании линейки продуктов, как определено в ISO26550:2015, проектирование домена дополняется проектированием приложений , которое занимается жизненным циклом отдельных продуктов, полученных из линейки продуктов. [1]
Доменная инженерия предназначена для улучшения качества разрабатываемых программных продуктов за счет повторного использования программных артефактов. [2] Доменная инженерия показывает, что большинство разрабатываемых программных систем являются не новыми системами, а скорее вариантами других систем в той же области. [3] В результате, благодаря использованию доменной инженерии, предприятия могут максимизировать прибыль и сократить время выхода на рынок, используя концепции и реализации из предыдущих программных систем и применяя их к целевой системе. [2] [4] Снижение стоимости очевидно даже на этапе внедрения. Одно исследование показало, что использование доменно-специфических языков позволило сократить размер кода, как по количеству методов , так и по количеству символов , более чем на 50%, а общее количество строк кода сократить почти на 75%. [5]
Инженерия домена фокусируется на сборе знаний, собранных в процессе разработки программного обеспечения . Разрабатывая повторно используемые артефакты, компоненты могут быть повторно использованы в новых программных системах с низкой стоимостью и высоким качеством. [6] Поскольку это применимо ко всем фазам цикла разработки программного обеспечения , инженерия домена также фокусируется на трех основных фазах: анализе, проектировании и реализации, параллельной разработке приложений. [7] Это создает не только набор компонентов реализации программного обеспечения, относящихся к домену, но также повторно используемые и настраиваемые требования и проекты. [8]
Учитывая рост данных в Интернете и рост Интернета вещей , подход к проектированию доменов становится актуальным и для других дисциплин. [9] Появление глубоких цепочек веб-сервисов подчеркивает, что концепция сервиса относительна. Веб-сервисы, разработанные и эксплуатируемые одной организацией, могут использоваться как часть платформы другой организацией. Поскольку сервисы могут использоваться в разных контекстах и, следовательно, требовать разных конфигураций, проектирование семейств сервисов может выиграть от подхода к проектированию доменов.
Инженерия домена, как и инженерия приложений, состоит из трех основных фаз: анализ, проектирование и реализация. Однако, если инженерия программного обеспечения фокусируется на одной системе, инженерия домена фокусируется на семействе систем. [7] Хорошая модель домена служит ссылкой для разрешения неоднозначностей на более поздних этапах процесса, хранилищем знаний о характеристиках и определении домена, а также спецификацией для разработчиков продуктов, которые являются частью домена. [10]
Анализ домена используется для определения домена, сбора информации о домене и создания модели домена . [11] Благодаря использованию моделей признаков (первоначально задуманных как часть метода анализа домена, ориентированного на признаки ), анализ домена направлен на выявление общих точек в домене и различных точек в домене. [12] Благодаря использованию анализа домена возможна разработка настраиваемых требований и архитектур, а не статических конфигураций, которые были бы созданы при традиционном подходе к проектированию приложений. [13]
Анализ домена существенно отличается от инженерии требований , и, как таковые, традиционные подходы к получению требований неэффективны для разработки настраиваемых требований, которые присутствовали бы в модели домена. Для эффективного применения инженерии домена повторное использование должно рассматриваться на ранних этапах жизненного цикла разработки программного обеспечения . Благодаря использованию выбора функций из разработанных моделей функций рассмотрение повторного использования технологии выполняется очень рано и может адекватно применяться на протяжении всего процесса разработки. [14]
Анализ домена в первую очередь выводится из артефактов, полученных из прошлого опыта в домене. [11] Существующие системы, их артефакты (такие как проектные документы , документы с требованиями и руководства пользователя ), стандарты и клиенты являются потенциальными источниками входных данных для анализа домена. [11] [15] Однако, в отличие от инженерии требований, анализ домена состоит не только из сбора и формализации информации; существует также творческий компонент. В процессе анализа домена инженеры стремятся расширить знания о домене за пределы того, что уже известно, и классифицировать домен по сходствам и различиям для улучшения реконфигурируемости. [11]
Анализ домена в первую очередь создает модель домена , представляющую общие и изменяющиеся свойства систем в домене. [11] Модель домена помогает создавать архитектуры и компоненты настраиваемым образом, выступая в качестве основы, на которой проектируются эти компоненты. [16] Эффективная модель домена не только включает изменяющиеся и последовательные функции в домене, но также определяет словарь, используемый в домене, и определяет концепции, идеи и явления в системе. [11] [17] Модели функций разлагают концепции на их обязательные и необязательные функции для создания полностью формализованного набора настраиваемых требований. [18]
Проектирование домена берет модель домена, созданную на этапе анализа домена, и стремится создать общую архитектуру, которой могут соответствовать все системы в домене. [19] Точно так же, как прикладная инженерия использует функциональные и нефункциональные требования для создания дизайна, фаза проектирования домена в проектировании домена берет настраиваемые требования, разработанные на этапе анализа домена, и создает настраиваемое стандартизированное решение для семейства систем. Проектирование домена направлено на создание архитектурных шаблонов, которые решают проблему, общую для систем в домене, несмотря на различные конфигурации требований. [20] В дополнение к разработке шаблонов во время проектирования домена инженеры также должны позаботиться об определении области действия шаблона и уровня, на котором контекст имеет отношение к шаблону. Ограничение контекста имеет решающее значение: слишком много контекста приводит к тому, что шаблон неприменим ко многим системам, а слишком мало контекста приводит к тому, что шаблон недостаточно мощный, чтобы быть полезным. [21] Полезный шаблон должен быть как часто повторяющимся, так и высококачественным. [22]
Целью проектирования домена является удовлетворение как можно большего числа требований домена, сохраняя при этом гибкость, предлагаемую разработанной моделью признаков. Архитектура должна быть достаточно гибкой, чтобы удовлетворять всем системам в домене, и в то же время достаточно жесткой, чтобы обеспечить прочную основу, на которой можно базировать решение. [23]
Реализация домена — это создание процесса и инструментов для эффективного создания индивидуальной программы в домене.
Инженерия домена подвергалась критике за то, что она слишком много внимания уделяла «инжинирингу для повторного использования» или «инжинирингу с повторным использованием» общих функций программного обеспечения, а не «инжинирингу для использования», чтобы мировоззрение, язык или контекст отдельного человека были интегрированы в проектирование программного обеспечения. [24]