В разработке программного обеспечения модель функций представляет собой компактное представление всех продуктов линейки программных продуктов (SPL) в терминах «функций». Модели функций визуально представлены с помощью диаграмм функций. Модели функций широко используются в течение всего процесса разработки линейки продуктов и обычно используются в качестве входных данных для создания других активов, таких как документы, определение архитектуры или фрагменты кода. [ необходима цитата ]
SPL — это семейство связанных программ. Когда единицами построения программы являются функции — приращения в функциональности программы или ее разработке — каждая программа в SPL идентифицируется уникальной и законной комбинацией функций, и наоборот.
Модели признаков были впервые введены Кангом в методе анализа предметной области, ориентированного на признаки (FODA), в 1990 году. [1] С тех пор моделирование признаков широко применялось сообществом разработчиков программных продуктов, и был предложен ряд расширений.
«Функция» определяется как «выдающийся или отличительный видимый пользователем аспект, качество или характеристика программной системы или системы». [1] Основное внимание при разработке SPL уделяется систематическому и эффективному созданию подобных программ. FODA — это анализ, посвященный идентификации функций в области, которая должна быть охвачена определенным SPL. [1]
Модель признаков — это модель, которая определяет признаки и их зависимости, обычно в форме диаграммы признаков + остаточных (т. н. перекрестных) ограничений. Но также она может быть представлена в виде таблицы возможных комбинаций. [ необходима цитата ]
Диаграмма признаков — это визуальная нотация модели признаков, которая по сути является деревом «и-или». Существуют и другие расширения: мощности , клонирование признаков, атрибуты признаков, обсуждаемые ниже.
Конфигурация функций — это набор функций, описывающий члена SPL: член содержит функцию тогда и только тогда, когда функция находится в его конфигурации. Конфигурация функций разрешена моделью функций тогда и только тогда, когда она не нарушает ограничений, налагаемых моделью...
Дерево функций (иногда также известное как Модель функций или Диаграмма функций) — это иерархическая диаграмма, которая визуально отображает функции решения в группах с возрастающими уровнями детализации. Деревья функций — это отличный способ суммировать функции, которые будут включены в решение, и то, как они связаны, простым визуальным образом. [2]
Текущие обозначения моделирования признаков можно разделить на три основные группы, а именно:
Отношения между родительским элементом и его дочерними элементами (или подэлементами) классифицируются следующим образом:
В дополнение к родительским отношениям между признаками допускаются ограничения по древовидной структуре. Наиболее распространенными являются:
В качестве примера, рисунок справа иллюстрирует, как модели функций могут использоваться для указания и создания настраиваемых систем онлайн-покупок. Программное обеспечение каждого приложения определяется функциями, которые оно предоставляет. Корневая функция (т. е. E-Shop) идентифицирует SPL. Каждая система покупок реализует каталог, платежные модули, политики безопасности и, по желанию, инструмент поиска. Электронные магазины должны реализовывать политику высокой или стандартной безопасности (выберите одну) и могут предоставлять различные платежные модули: банковский перевод, кредитная карта или оба из них. Кроме того, ограничение перекрестного дерева заставляет системы покупок, включая модуль оплаты кредитной картой, реализовывать политику высокой безопасности.
Некоторые авторы предлагают расширить базовые модели признаков с помощью UML -подобных множественностей вида [n,m] , где n — нижняя граница, а m — верхняя. Они используются для ограничения количества подпризнаков, которые могут быть частью продукта всякий раз, когда выбирается родитель. [3]
Если верхняя граница равна *, то функция может быть клонирована столько раз, сколько мы хотим (при условии соблюдения других ограничений). Эта нотация полезна для продуктов, расширяемых произвольным числом компонентов.
Другие предлагают добавлять дополнительную функциональную информацию к функциям с помощью «атрибутов». Они в основном состоят из имени, домена и значения. [4]
Семантика модели признаков — это набор конфигураций признаков, которые допускает модель признаков. Наиболее распространенный подход — использовать математическую логику для фиксации семантики диаграммы признаков. [5] Каждая характеристика соответствует булевой переменной , а семантика фиксируется как пропозициональная формула . Удовлетворительные оценки этой формулы соответствуют конфигурациям признаков, разрешенным диаграммой признаков. Например, если является обязательным подпризнаком , формула будет содержать ограничение . [6]
В следующей таблице представлен перевод основных примитивов. Мы предполагаем, что диаграмма представляет собой корневое дерево с корнем . Семантика всей диаграммы представляет собой конъюнкцию переводов элементов, содержащихся в диаграмме. Поэтому, если все элементы записаны в конъюнктивной нормальной форме (CNF), то термины можно легко объединить с помощью логического И, и все логическое выражение останется в CNF.
Продукт SPL декларативно указывается путем выбора или отмены выбора функций в соответствии с предпочтениями пользователя. Такие решения должны учитывать ограничения, налагаемые моделью функций. «Конфигуратор» — это инструмент, который помогает пользователю в процессе конфигурации. Например, автоматически выбирая или отменяя выбор функций, которые должны или не должны быть выбраны для успешного завершения конфигурации. Текущие подходы используют распространение единиц [7] и решатели CSP . [4]
Анализ модели функций нацелен на определенные свойства модели, которые важны для маркетинговых стратегий или технических решений. В литературе определен ряд анализов. [8] [9] Типичные анализы определяют, является ли модель функций недействительной (не представляет никаких продуктов), содержит ли она мертвые функции (функции, которые не могут быть частью какого-либо продукта) или количество продуктов в линейке программного продукта, представленных моделью. Другие анализы фокусируются на сравнении нескольких моделей функций (например, чтобы проверить, является ли модель специализацией , рефакторингом или обобщением другой ). [10]
