====== 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

===== Введение =====

Часто так получается, что во многих компаниях разрабатывают одни и те же программы (в смысле требуемых от них функций), используют одни и те же библиотеки, совершая при этом одни и те же ошибки. Для того чтобы сократить время разработки и избежать повторяющихся ошибок предполагается использовать 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:2016-12-25-062124_1308x588_scrot.png |}}
  - На вход подаются файлы с исходным кодом программ, изготовленных с помощью линейки ПО.
  - На основе этих файлов строятся FST с помощью фреймворка FeatureHouse
  - Из FST извлекается набор CP
  - Набор CP разбивается на классы эквивалентности относительно отношения "зависимость"(Здесь имеется ввиду зависимость между компонентами. По свойствам отношения эквивалентности ясно, что если есть зависимость, то CP лежат в одном классе эквивалентности).
  - Каждый из непересекающихся классов представляет собой feature.
  - С помощью фреймворка FeatureHouse генерируется код для features, полученных на предыдущем шаге.(Здесь опять же есть зависимость от целевого языка и для использования произвольного языка программирования требуется писать генератор кода из FST)

=====Пример парсинга кода на Java=====

===Исходный код 3х разных версий:===
{{ :mdd:2016-12-25-073714_1122x331_scrot.png |}}

===Соответствующие FST:===
{{ :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 

[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