Функциональная модель - Feature model

В разработке программного обеспечения функциональная модель компактное представление всех произведений Линия программных продуктов (SPL) с точки зрения «характеристик». Модели функций визуально представлены с помощью диаграмм функций. Модели функций широко используются в процессе разработки всей линейки продуктов и обычно используются в качестве входных данных для создания других активов, таких как документы, определение архитектуры или фрагменты кода.[нужна цитата ]

SPL - это семейство связанных программ. Когда единицами построения программы являются функции - приращение функциональности программы или развитие - каждая программа в SPL идентифицируется уникальной и допустимой комбинацией функций, и наоборот.

Модели функций были впервые представлены в Функционально-ориентированный анализ предметной области (FODA) Канг в 1990 году.[1] С тех пор функциональное моделирование было широко принято сообществом линейки программных продуктов, и был предложен ряд расширений.

Фон

«Особенность» определяется как «заметный или отличительный видимый для пользователя аспект, качество или характеристика программная система или система ".[1] Основное внимание при разработке SPL уделяется систематическому и эффективному созданию подобных программ. FODA - это анализ, посвященный идентификации функций в домене, на которые распространяется определенный SPL.[1]

Модель

Модель функций - это модель, которая определяет функции и их зависимости, обычно в форме диаграммы функций + оставшиеся ограничения (также известные как перекрестное дерево). Но также это может быть таблица возможных комбинаций.[нужна цитата ]

Диаграмма

Диаграмма функций - это визуальное обозначение модели функций, которая в основном представляет собой дерево и / или. Существуют и другие расширения: мощности, клонирование функций, атрибуты функций, обсуждаемые ниже.

Конфигурация

Конфигурация функции - это набор функций, который описывает член SPL: член содержит функцию тогда и только тогда, когда эта функция находится в его конфигурации. Конфигурация объекта разрешена моделью объекта тогда и только тогда, когда он не нарушает ограничений, налагаемых моделью.

Дерево функций

Дерево функций (иногда также известное как модель функций или диаграмма функций) - это иерархическая диаграмма, которая визуально изображает функции решения в группах с возрастающим уровнем детализации. Деревья функций - отличный способ обобщить функции, которые будут включены в решение, и то, как они связаны, простым визуальным образом.[2]

Обозначения моделирования функций

Текущие нотации моделирования признаков можно разделить на три основные группы, а именно:

  • Модели с основными функциями
  • Модели признаков на основе количества элементов
  • Модели с расширенными функциями

Модели с основными функциями

Отношения между родительским элементом и его дочерними функциями (или подчиненными функциями) подразделяются на следующие категории:

  • Обязательно - требуется дочерняя функция.
  • Необязательно - дочерняя функция не является обязательной.
  • Или - необходимо выбрать хотя бы одну из подфункций.
  • Альтернатива (xor) - необходимо выбрать одну из подфункций

В дополнение к родительским отношениям между объектами разрешены ограничения между деревьями. Наиболее распространены:

  • A требует B - Выбор A в продукте подразумевает выбор B.
  • A исключает B - A и B не могут быть частью одного и того же продукта.

В качестве примера на рисунке ниже показано, как можно использовать модели функций для определения и создания настраиваемых систем онлайн-покупок. Программное обеспечение каждого приложения определяется функциями, которые оно предоставляет. Корневая функция (например, Интернет-магазин) определяет SPL. Каждая торговая система реализует каталог, платежные модули, политики безопасности и, при необходимости, инструмент поиска. Интернет-магазины должны применять политику безопасности высокого или стандартного уровня (выберите один из них) и могут предоставлять различные платежные модули: банковский перевод, кредитную карту или и то, и другое. Кроме того, ограничение перекрестного дерева вынуждает торговые системы, включая модуль оплаты кредитной картой, реализовывать политику высокой безопасности.

Диаграмма функций, представляющая настраиваемую систему электронного магазина.


Модели признаков на основе количества элементов

Некоторые авторы предлагают расширить базовые модели функций с помощью UML -подобные кратности вида [п, м] с п нижняя граница и м верхняя граница. Они используются для ограничения количества дополнительных функций, которые могут быть частью продукта при выборе родительского элемента.[3]

Если верхняя граница м функцию можно клонировать столько раз, сколько мы захотим (при соблюдении других ограничений). Это обозначение полезно для продуктов, расширяемых с помощью произвольного числа компонентов.

Модели с расширенными функциями

Другие предлагают добавлять дополнительную функциональную информацию к функциям с помощью «атрибутов». В основном они состоят из имени, домена и значения.[4]

Семантика

Семантика модели функций - это набор конфигураций функций, которые допускает модель функций. Наиболее распространенный подход - использовать математическую логику для фиксации семантики диаграммы функций.[5] Каждой функции соответствует логическая переменная и семантика фиксируется как пропозициональная формула. Удовлетворительные оценки этой формулы соответствуют конфигурациям функций, разрешенным диаграммой функций. Например, если является обязательной подфункцией , формула будет содержать ограничение .[6]

В следующей таблице представлен перевод основных примитивов. Семантика диаграммы - это совокупность переводов элементов, содержащихся в диаграмме. Мы предполагаем, что диаграмма является корневым деревом.

Примитивная диаграмма функцийСемантика
это основная функция
необязательная подфункция
обязательная подфункция
альтернативные подфункции
или подфункции
исключает
требует

Настройка продуктов

Продукт SPL декларативно определяется путем выбора или отмены выбора функций в соответствии с предпочтениями пользователя. Такие решения должны учитывать ограничения, накладываемые функциональной моделью. «Конфигуратор» - это инструмент, который помогает пользователю в процессе настройки. Например, путем автоматического выбора или отмены выбора функций, которые должны или не должны, соответственно, выбираться для успешного завершения конфигурации. Современные подходы используют единичное распространение[7] и Решатели CSP.[4]

Свойства и анализы

Анализ модели характеристик нацелен на определенные свойства модели, которые важны для маркетинговых стратегий или технических решений. В литературе приводится ряд анализов.[8][9] Типичный анализ определяет, является ли модель функций недействительной (не представляет никаких продуктов), содержит ли она мертвые функции (функции, которые не могут быть частью какого-либо продукта) или количество продуктов линейки программных продуктов, представленных моделью. Другие анализы сосредоточены на сравнении нескольких моделей признаков (например, чтобы проверить, является ли модель специализация или же рефакторинг или же обобщение другого).[10]

Смотрите также

Рекомендации

  1. ^ а б c Канг, К. и Коэн, С.Г. и Хесс, Дж. и Новак, W.E. и Петерсон, A.S., «Исследование возможности анализа предметно-ориентированной области (FODA)», Технический отчет CMU / SEI-90-TR-021, SEI, Университет Карнеги-Меллона, ноябрь 1990 г.скачать
  2. ^ "Дерево функций | BAwiki".
  3. ^ Чарнецки К., Хелсен С. и Эйзенекер У., «Поэтапная конфигурация с использованием функциональных моделей», Труды Третьей Международной конференции по линиям программных продуктов (SPLC '04), том 3154 конспектов лекций по информатике. Springer Berlin / Heidelberg, август 2004 г. скачать.
  4. ^ а б Д. Бенавидес, П. Тринидад и А. Руис-Кортес. «Автоматизированное рассуждение о моделях признаков». 17-я конференция по передовой инженерии информационных систем (CAiSE'05). Порту, Португалия. 2005 г. скачать
  5. ^ Schobbens, P.-Y .; Heymans, P .; Триго, Ж.-К. "Диаграммы характеристик: обзор и формальная семантика, "Разработка требований, 14-я Международная конференция IEEE, том, №, стр.139-148, 11-15 сентября 2006 г." скачать
  6. ^ Амадор Дуран, Дэвид Бенавидес, Серхио Сегура, Пабло Тринидад и Антонио Руис-Кортес «FLAME: формальная основа для автоматизированного анализа линеек программных продуктов, подтвержденная автоматическим тестированием спецификаций». Программное и системное моделирование. 2015 г. скачать
  7. ^ Баторий, Д., «Модели характеристик, грамматики и формулы утверждений», Труды 9-й Международной конференции по линейке продуктов программного обеспечения (SPLC '05) скачать[постоянная мертвая ссылка ]
  8. ^ Д. Бенавидес, А. Руис-Кортес, П. Тринидад и С. Сегура. "Обзор автоматизированного анализа моделей признаков ". Jornadas de Ingeniería del Software y Bases de Datos (JISBD'06). Ситжес, Испания. 2006
  9. ^ Бенавидес, Дэвид; Сегура, Серджио; Руис Кортес, Антонио (2010). «Автоматический анализ моделей признаков 20 лет спустя: обзор литературы». Информационные системы. 35 (6): 615–636. Дои:10.1016 / j.is.2010.01.001. HDL:11441/24694.
  10. ^ Т. Тюм, Д. Баторий, К. Кестнер. "Рассуждения об изменениях в моделях элементов ". Международная конференция по программной инженерии (ICSE), май 2009 г.

внешняя ссылка