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


Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

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

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

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

Фон

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

Модель

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

Диаграмма

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

Семантика

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

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

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

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

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

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

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

  • Анализ предметной области
  • Доменная инженерия
  • Функционально-ориентированное программирование - парадигма синтеза линейки программных продуктов
  • Проектирование семейства продуктов
  • Линии программных продуктов

использованная литература

  1. ^ a b c Канг, К. К. и Коэн, С. Г. и Хесс, Дж. А. и Новак, В. Е. и Петерсон, А. С., «Технико-экономическое обоснование анализа предметно-ориентированной области (FODA)», Технический отчет CMU / SEI-90-TR-021, SEI , Университет Карнеги-Меллона, ноябрь 1990 г. скачать
  2. ^ "Дерево возможностей | BAwiki" .
  3. ^ Чарнецкий, К. и Helsen С. и Eisenecker, U., «Поэтапная конфигурациюиспользованием моделей функций», Труды Третьей Международной конференции по программному обеспечению Линии продукции (SPLC '04), объем 3154 из Lecture Notes вкомпьютерных наук. Springer Berlin / Heidelberg, август 2004 г. скачать .
  4. ^ а б Д. Бенавидес, П. Тринидад и А. Руис-Кортес. «Автоматизированное рассуждение о моделях признаков». 17-я конференция по передовой инженерии информационных систем (CAiSE'05). Порту, Португалия. 2005 скачать
  5. ^ Schobbens, P.-Y .; Heymans, P .; Триго, Ж.-К., " Диаграммы характеристик: обзор и формальная семантика ", Разработка требований, 14-я Международная конференция IEEE, том, №, стр. 139-148, 11-15 сентября 2006 г. скачать
  6. ^ Амадор Дуран, Дэвид Бенавидес, Серхио Сегура, Пабло Тринидад и Антонио Руис-Кортес «ПЛАМЯ: формальная структура для автоматизированного анализа линеек программных продуктов, подтвержденная автоматическим тестированием спецификаций». Программное и системное моделирование. 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. DOI : 10.1016 / j.is.2010.01.001 . ЛВП : 11441/24694 .
  10. ^ Т. Туэм, Д. Баторий и К. Кестнер. « Рассуждения об изменениях в моделях функций ». Международная конференция по программной инженерии (ICSE), май 2009 г.

внешние ссылки

  • Вики-сайт репозитория моделей функций
  • Разработка линейки программных продуктов с использованием моделей функций
Источник « https://en.wikipedia.org/w/index.php?title=Feature_model&oldid=951689160 »