mdd:spl_reverse

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:spl_reverse [2016/12/25 02:05] – [Введение] grapefrootmdd:spl_reverse [2026/08/29 07:59] (current) – external edit 127.0.0.1
Line 1: Line 1:
 +====== Towards a Language-Independent Approach for Reverse-Engineering of Software Product Lines ======
  
 +На основе статьи:
 +
 + Tewfik Ziadi, Christopher Henard, Mike Papadakis, Mikal Ziane, and Yves Le Traon. 2014. Towards a language-independent approach for reverse-engineering of software product lines. In Proceedings of the 29th Annual ACM Symposium on Applied Computing (SAC '14). ACM, New York, NY, USA, 1064-1071. DOI: [[http://dx.doi.org/10.1145/2554850.2554874|http://dx.doi.org/10.1145/2554850.2554874]]
 +
 +===== Введение =====
 +
 +Часто так получается, что во многих компаниях разрабатывают одни и те же программы (в смысле требуемых от них функций), используют одни и те же библиотеки, совершая при этом одни и те же ошибки. Для того чтобы сократить время разработки и избежать повторяющихся ошибок предполагается использовать feature-based подход, то есть собирать желаемый функционал системы из некоторого высокоуровневого конструктора. Будет рассмотрен алгоритм восстановления частей конструктора(то есть выделение feature) на основе исходного кода программ, сгенерированных с его помощью. Утверждается, что алгоритм не нуждается в каких-то специальных пометках в коде и не зависит от используемого языка программирования.
 +
 +===== Терминология =====
 +
 +В статье активно используются различные термины. Хорошо бы их пояснить.
 +
 +  * Feature - одно из требований к продукту
 +  * Software Product Line (SPL) - Линейка ПО - высокоуровневый конструктор, позволяющий быстро собрать систему, отвечающую заданным требованиям из набора компонент
 +  * FST - Дерево синтаксического разбора для требований. Подробнее описано в [1]. Строго говоря, построение такого дерева зависит от языка, но авторы в [1] утверждают, что это “requires only a few hours of effort”(с). Каждой версии конечного ПО соответствует набор поддеревьев FST или набор CP.
 +  * Construction Primitive(CP) - Вершина в дереве разбора. Одна из деталей конструктора. Может быть обязательной для приложения или необязательной.
 +  * Set of components(SoCPs) - набор CP
 +
 +===== Описание алгоритма =====
 +
 +== Еще немного определений ==
 +
 +Пусть <latex> AllP </latex> - набор всех программных продуктов, из которых мы хотим извлечь features. Тогда для элементов  <latex> cp_1, cp_2 \in AllCP </latex> - набора всех СP определяется следующее отношение эквивалентности:
 +
 +== Отношение эквивалентности "зависимость": ==
 +
 + <latex>(\exists P \in AllP cp_1 \in P \wedge cp_2 \in P ) \wedge (\forall P \in AllP cp_1 \in P \Leftrightarrow cp_2 \in P)</latex>
 +Легко заметить, что это бинарное отношение является отношением эквивалентности.
 +
 +== Теперь сам алгоритм: ==
 +
 +[[mdd:_detail:mdd:2016-12-25-062124_1308x588_scrot.png|]]
 +
 +  - На вход подаются файлы с исходным кодом программ, изготовленных с помощью линейки ПО.
 +  - На основе этих файлов строятся FST с помощью фреймворка FeatureHouse
 +  - Из FST извлекается набор CP
 +  - Набор CP разбивается на классы эквивалентности относительно отношения “зависимость”(Здесь имеется ввиду зависимость между компонентами. По свойствам отношения эквивалентности ясно, что если есть зависимость, то CP лежат в одном классе эквивалентности).
 +  - Каждый из непересекающихся классов представляет собой feature.
 +  - С помощью фреймворка FeatureHouse генерируется код для features, полученных на предыдущем шаге.(Здесь опять же есть зависимость от целевого языка и для использования произвольного языка программирования требуется писать генератор кода из FST)
 +
 +===== Пример парсинга кода на Java =====
 +
 +=== Исходный код 3х разных версий: ===
 +
 +[[mdd:_detail:mdd:2016-12-25-073714_1122x331_scrot.png|]]
 +
 +=== Соответствующие FST: ===
 +
 +[[mdd:_detail:mdd:2016-12-25-073658_784x536_scrot.png|]]
 +
 +===== Проблемы данного подхода =====
 +
 +Этот подход является высокоуровневым, что лишает его гибкости и препятствует более широкому. Также он никак не учитывает возможные ограничения на выбор features. А ведь они могут быть взаимоисключающими. Для достижения независимости от языков нужно писать и поддерживать парсер для FeaturesHouse. Если посмотреть на статью [1], то можно понять что написать хороший парсер можно только для объектно-ориентированных языков. Чтобы написать такой парсер для Haskell или C, нужно наложить дополнительные ограничения на структуру кода.
 +
 +===== Список литературы =====
 +
 +[1]  Sven Apel, Christian Kastner, and Christian Lengauer. 2009. FEATUREHOUSE: Language-independent, automated software composition. In Proceedings of the 31st International Conference on Software Engineering (ICSE '09). IEEE Computer Society, Washington, DC, USA, 221-231. DOI=10.1109/ICSE.2009.5070523 [[http://dx.doi.org/10.1109/ICSE.2009.5070523|http://dx.doi.org/10.1109/ICSE.2009.5070523]]
 +
 +[2]  Tewfik Ziadi, Christopher Henard, Mike Papadakis, Mikal Ziane, and Yves Le Traon. 2014. Towards a language-independent approach for reverse-engineering of software product lines. In Proceedings of the 29th Annual ACM Symposium on Applied Computing (SAC '14). ACM, New York, NY, USA, 1064-1071. DOI: [[http://dx.doi.org/10.1145/2554850.2554874|http://dx.doi.org/10.1145/2554850.2554874]]