mdd:automated_analysis

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision		 Previous revision
mdd:automated_analysis [2016/12/23 20:38] – [Введение] yaroshenkopolinamdd:automated_analysis [2026/08/29 07:59] (current) – external edit 127.0.0.1
Line 1: Line 1:
 +======Automated Analysis in Feature Modelling and Product Configuration======
  
 +Оригинал: David Benavides, Alexander Felfernig, Jose A. Galindo, and Florian Reinfrank, (2013) Automated Analysis in Feature Modelling and Product Configuration\\
 +[[https://www.google.ru/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0ahUKEwiKz7vszo_RAhWLjSwKHZ2oDqMQFggkMAE&url=http%3A%2F%2Fwww.lsi.us.es%2F~dbc%2Fen%2F%3Fdownload%3Dbenavides13-icsr.pdf&usg=AFQjCNFp_5jMxWp6gOHmyOXtHpMMGAGs2g&sig2=ldNzX0Q6HM-DLQ-ljAM1jA&cad=rjt]]
 +====Введение====
 +
 +Моделирование и управление изменчивостью системы является ключевым фактором в разработке программного обеспечения. Feature model(модель признаков) является одним из самых распространенных механизмов для моделирования изменчивости в течение разработки. Существуют три вида модели признаков: основная модель признаков, модель признаков основанная на мощности и расширенная модель признаков. Модель состоит из набора признаков и отношений, которые связывают эти признаки. На рисунке ниже можно увидеть пример модели, которая использует все основные элементы.
 +
 +
 +{{:mdd:снимок_экрана_2016-12-23_в_18.25.18.png|}}
 +
 +Автоматический анализ моделей признаков является одной из самых привлекательных тем для исследований в последние 20 лет. На вход будет приниматься сама модель с дополнительным описанием, а на выходе будут получаться конкретные числа или наборы признаков в зависимости от типа операций, проводимых в анализе. Общий процесс анализа можно увидеть на схеме ниже.
 +
 +{{:mdd:снимок_экрана_2016-12-23_в_18.40.11.png|}}
 +
 +Исследование конфигураций продуктов не является частью разработки программного обеспечения, но изучение объединения имеет большой потенциал.
 +
 +====Вопросы для исследования ====
 +
 +**RQ1: **Как связаны различные методы моделирования друг с другом?\\
 +**RQ2: **Какие автоматические механизмы будут использоваться?\\ 
 +**RQ3: **Есть ли схожие операции?\\
 +**RQ4: **Как тестировать функциональность и эффективность?\\
 +
 +====Предварительные результаты====
 +
 +**RQ1: Как связаны различные методы моделирования друг с другом?**\\
 +
 +Сначала попробуем ответить на следующий вопрос: //Может ли проблема конфигурации модели признаков быть представлена как проблема конфигурации?// Чтобы это сделать, введем несколько определений:\\
 +**Определение 1 (Проблема Конфигурации Модели Признаков)**\\
 +Проблема конфигурации модели признаков определяется множеством (F, D, C),\\ где F = {f<sub>1</sub>, f<sub>2</sub>, ... , f<sub>n</sub>}, набор признаков f<sub>i</sub>,\\ 
 +D = {dom(f<sub>1</sub>), dom(f<sub>2</sub>), ... , dom(f<sub>n</sub>)}, где dom(f<sub>i</sub>) = {true, false}\\
 +C = CR U CF, где CR = {c<sub>1</sub>, c<sub>2</sub>, ... , c<sub>k</sub>} множество требований пользователей, CF = {c<sub>k+1</sub>, c<sub>k+2</sub>, ... , c<sub>m</sub>,} множество ограничений модели признаков.\\ 
 +Гипотеза заключается в том, что любые отношения, определенные на языке модели признаков, могут быть переведены в ограничения CSP(Constraint Satisfaction Problem).\\
 +**Определение 2 (Конфигурация Модели Признаков)**\\
 +Конфигурация модели признаков для данной проблемы конфигурации модели признаков - это полное присвоение значение переменным\\ f<sub>i</sub> ∈ F. Конфигурация считается согласованной, если c<sub>i</sub> ∈ C согласованы с заданными значениями переменных.\\ 
 +**Результат:** Проблемы конфигурации модели признаков и любая проблема в конфигурации программного обеспечения может рассматриваться как проблема конфигурации продукта.
 +
 +**RQ2: Какие автоматические механизмы будут использоваться?**\\
 +Известные методы основаны на CCSP(conditional constraint satisfaction problems), DCSP(dynamic constraint satisfaction problems), GCSP(generative constraint satisfaction problems), BDD(binary decisions diagrams). Чтобы представлять и решать проблемы конфигурации, предлагается комбинировать CCSP и BDD.
 +
 +**RQ3: Есть ли схожие операции?**\\
 +
 +Для анализа модели признаков есть 30 различных операций, для конфигурации продукта есть только базовые операции. Например, в анализе модели признаков есть операция //"Объяснение"//, результат которой объясняет //почему// был выдан именно он. А это занимает гораздо больше времени, по сравнению с базовыми операциями. Механизм объяснения должен быть синхронизирован с механизмом обработки конфигурации продукта, поэтому предлагается давать объяснение, которое будет сохранять минимальное количество действий, нужных для устранения недостатков конфигурации, или сфокусироваться на определение конкретных недостатков, которые не обязательно требуют небольших усилий для устранения.
 +
 +**RQ4: Как тестировать функциональность и эффективность?**\\
 +
 +В тестировании функциональности модели признаков используются методы тестирования чёрным ящиком, такие как FaMa и SPLOT. Однако, методы, которые бы предоставляли систематическое тестирование конфигураций, не были найдены.
 +
 +====Заключение и дальнейшие действия====
 +
 +Анализ модели признаков и конфигурация продуктов имеют много общего. Взаимное развитие этих двух независимых областей является необходимым шагом для улучшения разработки программного обеспечения.\\
 +====Список литературы====
 +1. Configuration Benchmarks Library.\\
 +2. M. Acher, B. Baudry, P. Heymans, A. Cleve, and J. Hainaut. Support for reverse engineering and maintaining feature models. In Proceedings of the Seventh Interna- tional Workshop on Variability Modelling of Software-intensive Systems, page 20. ACM, 2013.\\