Систематическое управление изменчивостью* в линейках программных продуктов, основанных на UML (Smarty)

Оригинал: Edson A. Oliveira Junior, Itana M. S. Gimenes, Jos´e C. Maldonado

В сфере программного обеспечения в последнее время все большую популярность приобретает подход разработки целой линейки программных продуктов (Product Line, PL). Экономические соображения IT-компаний по поводу стоимости и времени выхода одного продукта идейно привели индустрию к выше упомянутой методике, по которой продукты разрабатываются в форме много повторного использования перспективы. PL подход основывается на модели двух жизненного цикла: управляемая инженерия (domain engineering), где основной актив PL разрабатывается с целью повторного использования, и прикладная инженерия (application engineering), где основной актив используется для создания уже конкретных продуктов. Успех данного подхода зависит от нескольких принципов, в частности, от гибкого управления.

Однако, сейчас нет ни одного главного общепринятого виденья, которое бы объясняло, как быть с изменчивостью в PL артефактах, основанных на UML. Данная статья описывает подход SMarty (Stereotype-based Management of Variability), который способен решить эту проблему. Он состоит из 2х методов: UML профиль, SMartyProfile, и систематическое гибкое управление процессом, SMartyProcess.

SMartyProfile содержит набор шаблонов и отмеченных значений, отображающих изменчивость в моделях PL. В основном, SMartyProfile использует стандартное объектно-ориентированное обозначение и его механизмы, расширяет UML, дает графическое представление понятий изменчивости. Таким образом, нет необходимости менять структуру проектирования системы, чтобы соответствовать подходу PL. SMartyProcess представляет собой систематический процесс, который ведет пользователя через идентификации, разграничения, представления и отслеживания вариабельности в моделях PL. Данный метод поддерживается набором руководящих принципов применения, а также с помощью SMartyProfile для представления изменчивости.

Рис.1 SMartyProfile отображает взаимосвязь основных понятий PL в смысле управления изменчивостью. Здесь существует 4 основных понятия: вариабельность, точка вариации, вариант, и вариант ограничения. Основываясь на этих концепциях, рисунок 1 представляет SMartyProfile, который состоит из следующих шаблонов и соответствующих указанных значений:

1. «variability» (вариабельность) - представляет понятие изменчивости PL и является расширением метакласса Comment. Данный шаблон имеет следующие переменные:
   • name – указываемое имя, через которое мы можем ссылаться на шаблон;
   • minSelection – минимальное кол-во вариантов, которые будут выбраны с целью нахождения точки вариабельности или самой вариабельности;
   • maxSelection – максимальное кол-во вариантов, которые будут выбраны с целью нахождения точки вариабельности или самой вариабельности;
   • bindingTime – момент времени, в который вариабельность должна быть разрешена, представлена классом BindingTime;
   • allowsAddingVar – указывает на то, возможно ли включать новые варианты развития PL;
   • variants – коллекция возможных вариантов вариабельности;
   • realizes – коллекция моделей вариабельности, которые реализуют вариабельность.
2. «variationPoint» (точка вариации) - представляет собой в PL концепцию точки вариации и является расширением метаклассов Actor, UseCase, Interface и Class. Данный шаблон включает в себя следующие переменные:
   • numberOfVariants – инициализирует число связанных вариантов, которые могут быть выбраны с целью нахождения точки вариации;
   • bindingTime - момент времени, в который точка вариации должна быть разрешена, представлена классом BindingTime;
   • variants – коллекция возможных экземпляров, связанных с этой точкой вариации;
   • variabilities – коллекциях связанных изменчивостей.
3. «variant» (вариант) - представляет собой концепцию варианта в PL и является расширением метаклассов Actor, UseCase, Interface, Class. Данный шаблон специализируется на 4х других неабстрактных шаблонах: «mandatory», «optional», «alternative OR», «alternative XOR». Содержит следующие переменные:
   • rootVP – точка вариации, с которой связан вариант;
   • variabilities – коллекция связанных изменчивостей.
4. «mandatory» - представляет собой обязательный вариант, который является частью каждого из продуктов в PL.
5. «optional» - необязательный вариант, который может быть выбран с целью разрешения точки вариации или изменчивости.
6. «alternative OR» - представляет собой вариант, который является частью группы альтернативных включаемых вариантов. Различного комбинации таких вариантов могут по-разному разрешить точку вариации или вариабельности.
7. «alternative XOR» - вариант, который является частью группы альтернативных особых вариантов. Это значит, что только один вариант этой группы может быть выбран для разрешения точки вариации или изменчивости.
8. «mutex» - представляет собой концепцию PL варианта скованного и взаимоисключающего отношения между двумя вариантами. Это означает, что если выбран один вариант, другой выбран быть уже не может.
9. «requires» - концепция PL варианта и связующее звено между двумя вариантами, в которых выбранный вариант диктует необходимость выбора другого конкретного варианта.
10. «variable» - расширение метакласса Component. Указывает на то, имеет ли компонент набор классов с явной вариабельностью. Этот шаблон имеет единственную переменную classSet – коллекция экземпляров класса, которые формируют составляющую.

Деятельность SMartyProcess напрямую связана с общим процессом развития разработки линейки программных продуктов. На рисунке 2 показано встраивание новой технологии (справа) в привычную старую (слева) на протяжении всего процесса разработки ПО, что приводит к увеличению вариабельности, как факт. Как видно из диаграммы, SMartyProcess является многократным и постепенным процессом, который работает параллельно с развитием PL и использует выходные данные из основного актива развития PL в качестве входных (на ровне с предоставляемой информацией). Например, диаграмма вариантов использования и диаграмма классов подаются на вход SMartyProcess, но продолжают использоваться в основном активе разработки PL. Тем не менее, некоторые модели, такие, как отслеживания и реализации изменчивости, возникают сами по себе.

Рис.2 ‘Variability Tracing Definition’ принимает на вход варианты использования и характеристическую модель, построенных в процессе разработки PL. Модель трассировки изменчивости строится в соответствие со следующими правилами: (i) отмеченные особенности PL перечислены; (ii) отмеченные варианты использования перечислены; (iiI) взаимосвязи между особенностями и вариантами использования повторно проанализированы; (iv) пересечения между использованными случаями и особенностями отмечены. Данная модель представляется в табличной форме и поддерживает трассирование от функций для всех UML моделей PL.

В каждую итерацию между PL разработкой и SMartyProcess, ‘Variability Identification’ постепенно принимает в качестве входных данных варианты использования, функции, класс и модель компонентов. Цель данной деятельности – выявление изменчивости, связанной с моделями. SMartyProfile основательно поддерживает развитие этой деятельности, применяя своими шаблоны к моделям PL. ‘Variability Identification’ напрямую зависит от управляемой инженерии, что требует внимания PL менеджеров и аналитиков. Далее, предлагаются рекомендации для поддержания данной деятельности:

1. Элементы моделей вариантов использования связаны с расширением и точками расширения механизма.
2. В моделях класса точки вариации и их варианты определены в следующих обозначениях: обобщение - наиболее общие классификаторы являются точками вариации; реализация интерфейса – поставщики (спецификации) являются точками вариации и реализации (клиенты) – это варианты; агрегация ассоциации – набранные экземпляры с пустыми инстансами – это точки вариации, а связанные с ними набранные экземпляры являются классами; композитная агрегация – печатаемые экземпляры с заполненными инстансами – точки вариации и связанные с ними набранные экземпляры – варианты.
3. Элементы моделей вариантов использования ссылаются на включение (зависимость) или ассоциацию с актерами отношений. Предполагаются либо обязательные, либо необязательные варианты.
4. Элементы моделей классов связаны отношением, в котором атрибут aggregationKind имеет нулевое значением, т.е. ни агрегация, на композиция не предполагают необязательные варианты.
5. Компоненты, в моделях компонент, с точкой вариации или классами вариации указаны шаблонами как «variable».

‘Variability Delimitation’ направлена на определение следующих атрибутов изменчивости: (i) multiplicity (кратность); (ii) binding time (время разрешения); (iii) возможность (possibility) добавления новых элементов к соответствующему множеству вариантов. Кратность изменчивости определяет минимальное (поле minSelection) и максимальное (поле maxSelection) количество элементов данного варианта, которые должны быть выбраны для решения варианта. Применяются следующие правила: (i) вариабельности с дополнительными вариантами имеют кратность: minSelection = 0, maxSelection = 1; (ii) вариабельности с особыми альтернативными вариантами имеют кратность: minSelection = maxSelection = 1; (iii) вариабельности с включающимися альтернативными вариантами имеют кратность: minSelection = 1, maxSelection = кол-во вариантов.

Определение Binding Time имеет важное значение для определения выбора механизмов осуществления, описанных в следующей деятельности.

‘Identification of Mechanisms for Variability Implementation’ направлен на выбор механизмов, которые будут использоваться для реализации изменчивости. На входе – модели классов и компонент с их соответствующими вариабельностями, представленными и разграниченными в результате предыдущей деятельности. На выходе данной деятельности – модель реализации, представленная в виде таблице. Каждая строка таблицы содержит имя изменчивости, элемент, в котором она происходит, время разрешения, механизм реализации, а также стратегия осуществления. Среди этих техник – обобщение, расширение, параметризация.

‘Variability Tracing and Control’ использует изменяемую метамодель для описания взаимосвязей между различными артефактами PL и их точками вариации, вариантов, времени разрешения и механизмов реализации. Вместе с моделью отслеживания изменчивости эта метамодель позволяет ассоциацию функции с соответствующими прецедентами и, следовательно, с элементами моделей классов и компонентов. Выполнение этой деятельности состоит из экземпляра метамодели для PL.

'Configuration Analysis of Specific Products’ направлена на изучение влияния выбора возможных особенностей PL артефактов с целью анализа целесообразности производства конкретных PL продуктов. Выбор особенности может означать выбор конфигурации продукта в соответствии с описанными точками вариации. Кроме того, зависит от того, требуется продукту дополнительной особенности или нет, введение этой функции должно быть обязательно проанализировано в PL артефактах.

Ниже приведена построение SMarty модели при разработке аркадной PL игры.

Рис.3 Рис.4 Рис.5 Рис.6

• [Bosch 04] Bosch, J.: Preface. In: Proceedings of the 2nd Groningen Workshop on Software Variability Management: Software Product Families and Populations, Groningen, The Netherlands (2004)
• [Bragan¸ca, Machado 06] Bragan¸ca, A., Machado, R. J.: Extending UML 2.0 Metamodel for Complementary Usages of the extend Relationship within Use Case Variability Specification. In: Proceedings of the 10th International Software Product Line Conference, pp. 123–130. (2006)
• [Chen et al. 09] Chen, L., Babar, M. A. and Ali, N.: Variability Management in Software Product Lines: A Systematic Review. In: Proceedings of the XIII Software Product Line International Conference, pp. 81–90. (2009)
• [Clauß 01] Clauß, M.: Generic Modeling Using UML Extensions for Variability. In:Proceedings of Workshop on Domain Specific Visual Languages, pp. 11–18. TampaBay (2001)
• [Gomaa 05] Gomaa, H.: Designing Software Product Lines with UML: from Use Cases to Pattern-based Software Architectures. Addison-Wesley, (2005)
• [Halmans, Pohl 03] Halmans, G., Pohl, K.: Communicating the Variability of a Software-Product Family to Customers. Springer-Verlag, New York (2003)
• [Jacobson et al. 97] Jacobson, I., Griss, M. L., Jonsson, P.: Software Reuse: Architecture, Process and Organization for Business Success. Addison-Wesley, (1997)
• [Korherr, List 07] Korherr, B., List, B.: A UML 2 Profile for Variability Models and their Dependency to Business Processes. In: Proceedings of the 18th International Conference on Database and Expert Systems Applications, pp. 829–834 (2007)
• [Linden et al. 07] Linden, F. J. van der, Schmid, K., Rommes, E.: Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering. Springer-Verlag, New York (2007)
• [Oliveira Junior et al. 05] Oliveira Junior, E. A., Gimenes. I. M. S., Huzita, E. H. M., Maldonado, J. C.: A Variability Management Process for Software Product Lines. In: Proceedings of the 2005 Conference of the Centre for Advanced Studies on Collaborative Research, pp. 225–241. IBM Press, Toronto, Ontario, Canada (2005)
• [Oliveira Junior et al. 08] Oliveira Junior, E. A., Gimenes, I. M. S., Maldonado, J. C.: A Metric Suite to Support Software Product Line Architecture Evaluation. In: Proceedings of the 34th Conferencia Latinoamericana de Inform´atica, pp. 489–498. Santa F´e, Argentina (2008)
• [Pohl et al. 05] Pohl, K., B¨ockle, G., Linden, F. J. van der: Software Product Line Engineering: Foundations, Principles and Techniques. Springer-Verlag, New York (2005)
• [SEI-AGM 09] SEI - Arcade Game Maker Pedagogical Product Line, http://www.sei.cmu.edu/productlines/ppl
• [Svahnberg et al. 05] Svahnberg, M., van Gurp, J., Bosch, Jan: A Taxonomy of Variability Realization Techniques: Research Articles. Software Practice and Experience. v.35, n.8, pp. 705–754 (2005)
• [UML 09] OMG - UML Specification - Superstructure v2.2, http://www.omg.org/cgi-bin/doc?formal/09-02-02
• [Ziadi et al. 03] Ziadi, T., H´elou¨et, L., J´ez´equel, J. M.: Towards a UML Profile for Software Product Lines. In: Proceedings of the Product Family Engineering, pp. 129–139. (2003)

*изменчивость (вариабельность) - понятие, обозначающее наличие нескольких направлений в разработке конкретного ПО