CC BY
17
Романов В.Ю.
факультет ВМК МГУ им. М.В. Ломоносова, vromanov @ cs . msu . su, vladimir. romanov @ gmail . com
Использование шаблонов пакетов при извлечении архитектуры программных систем
КЛЮЧЕВЫЕ СЛОВА
Визуализация программного обеспечения, визуализация пакетов, извлечение архитектуры, шаблоны пакетов, обратное проектирование.
АННОТАЦИЯ
В статье рассматриваются особенности CASE-инструмента для моделирования свободно распространяемого программного обеспечения разработанного на языке Java[1]. Данный инструмент предназначен для моделирования, визуализации и извлечения архитектуры такого программного обеспечения с помощью языка UML. Для решения задачи извлечения архитектуры зачастую используется подход анализа иерархии компонент программной системы сверху вниз. Некоторые инструменты при этом предоставляют возможность выполнять извлечение в интерактивном режиме, оперативно предоставляя архитектурно важные виды (точки зрения на систему) на рассматриваемые элементы программной системы. Эти виды позволяют визуально оценить структуру рассматриваемого элемента и его связи с другими элементами. В статье рассматривается использование шаблонов пакетов языка Java для упрощения решения такой задачи.
1.Введение
Одним из распространенных определения архитектуры [2] является следующее: архитектура программной системы или вычислительной системы есть структура или структуры этой системы, видимые извне системы, видимые извне свойства этих элементов и видимые извне отношения между ними.
Существует ряд инструментов поддерживающих выделение и извлечение архитектуры системы, в которых существенную роль играют интерактивность и визуализация [3, 4, 5, 6]. Некоторые шаги в этом процессе (извлечение элемента модели программной системы и генерация видов элемента модели) часто автоматизированы и не требуют какого либо вмешательства человека.
2. Извлечение архитектуры
В случае больших программных систем архитектура описывается посредством нескольких архитектурных видов (architectural view), каждых из которых соответствует одной из предопределенных точек зрения (viewpoint)[7, 8, 9, 10]. Наиболее распространенные и общепринятые виды следующие:
1. Модульные виды представляют модули системы и их отношения полученные в результате анализа кода;
2. Виды компонентов и соединители, представляющие такие компоненты периода выполнения как серверы, процессы и базы данных, а также механизмы общения компонент друг с другом, например, сокеты и удаленные вызовы процедур;
3. Виды внедрения показывающие расположение модулей и компонент в среде их разработки и в среде их исполнения.
Далее в статье будут рассматриваться модульные виды архитектуры. В рассматриваемом нами случае программной системы написанной на языке Java под модулями мы будем понимать пакеты языка Java, поскольку в данный момент в языке Java явные конструкции для модулей отсутствуют.
Инструмента автоматического анализа программной системы рассматривает сверху вниз иерархическую декомпозицию системы представленную в виде UML-модели системы[10]. Начинается анализ с вида самого верхнего уровня UML-модели. Последовательные раскрытия и сжатия элементов в иерархии элементов модели приводят к формированию рабочего множества элементов видимых в данный момент времени.
Расширить А Расширить В
.....................4^/'.......................х^
0 ® Сжать 0 @ Сжать £)
А © <§>
Ря&эчез множества Рабочее множества С Л© (А1,А2,Ш
Еид секции
©fe
Рабочее множества (А1, А2. В1, Б2
Рис.1. Последовательность применения операций Раскрыть и Сжать при анализе
программной системы Виды являются подходящими для описания архитектуры программной системы, когда все модули (пакеты языка Java) в рабочем множестве важны для описания архитектуры, а также все такие модули
расположены на правильном уровне абстракции. Далее нам необходимо будет классифицировать виды связей между модулями (пакетами) языка Java.
Зависимости между пакетами
В языке Java нет явной конструкции для задания модулей исходного кода. Исходные тексты на этом языке структурируются с помощью пакетов, а связи задаются с помощью предложений импорта в типы языка Java (классы, интерфейсы и перечисления) типов из других пакетов.
Описания зависимостей между пакетами с помощью конструкции импорта бывает недостаточно при некоторых типах анализа программной системы. Отношения зависимости между пакетами часто необходимо собрать на верхнем уровне, подняв для этого зависимости между пакетами нижнего уровня на верхние уровни, а зависимости между классами должны быть подняты на уровень содержащих эти классы пакетов на уровень пакетов.
Зависимости между типами возникают вследствие отношений наследования между классами, реализации интерфейсов классами, вызова методов из других классов, доступа к полям других классов.
сз
а
С1
CS
с:
_ Расширен нал зависимость
^Ограниченная зависимость
Вызов
Рис.2. Два вида зависимости между пакетами
Ограниченная зависимость — это зависимость между двумя ограниченными пакетами. Она представляет все явные зависимости нижнего уровня существующими между двумя ограниченными пакетами. На рисунке 2 зависимость между ограниченными пакетами В и D содержит вызовы методов между классами С1 и С2. Зависимости между ограниченными пакетами А и С не существует.
Расширенная зависимость — это зависимость между двумя расширенными пакетами. Она представляет множество всех явных зависимостей между элементами определенными в двух расширенных пакетах. На рисунке 2 зависимость между расширенными пакетами А и С содержит два вызова: один из класса С1 в класс С2, и одни из класса С1 в С5.
Оба вида отношений между пакетами направленные. Будем называть такие отношения также входящими и выходящими.
Классификация ограниченных пакетов
Характеризуем расширенный пакет используя его взаимодействие с другими пакетами в рабочем множестве. Для этого будем характеризовать
взаимодействие каждого из его вложенных пакетов с расширенными пакетами рабочего множества. На основе его взаимодействия с множеством расширенных пакетов в рабочем множестве, ограниченный пакет может быть четырех типов:
Тихий — рассматриваемый пакет не имеет взаимодействия с расширенными пакетами рабочего множества.
Потребитель — существует отношение направленное от рассматриваемого ограниченного пакета к по меньшей мере к одному из пакетов рабочего множества.
Поставщик — пакет для которого существует по меньшей мере одно отношение зависимости из пакета в рабочем множестве в рассматриваемый пакет.
Гибридный — пакет, для которого есть зависимости в обоих направлениях между рассматриваемых ограниченным пакетом и пакетом в рабочем множестве.
Для кодирования на диаграммах степени зависимости будем использовать цвет, как показано на рисунке 3.
Количество выходящих вызовов
Количество входящих вызовов
Рис. 3. Кодирование степени зависимости В соответствии с такой кодировкой рассмотренные типы пакетов будут иметь следующий вид:
Тихий ^^^ Потребитель | Поставщик Гибоншнн
Рис. 4. Кодирование типов пакетов Пример расширенного пакета приведен на рисунке 5.
Рис. 5. Пример расширенного пакета
Шаблоны пакетов при извлечении архитектуры
При анализе программной системы с автоматическим построением архитектурных видов для текущего рабочего множества были обнаружены четыре часто встречающихся шаблона задающих определенные взаимосвязи пакетов. Автоматическое распознавание таких шаблонов в программной системе существенно упрощает построение архитектурных видов для программной системы в целом.
Шаблон Айсберг. Айсберг — это пакет от которого зависят другие пакеты рабочего множества. Однако эта зависимость лишь с ограниченной версией пакета — айсберга. Пакеты вложенные в айсберг скрыты от пакетов рабочего множества.
О
Рис. 6. Примеры шаблона Айсберг Пакет в вершине айсберга не нуждается в дальнейшем расширении. Хотя пакеты, вложенные в пакет-вершину айсберга, и используют другие пакеты, однако для понимания архитектуры других пакетов расширение не предоставит дополнительной информации. Все необходимые для понимания связи предоставляются вершиной айсберга.
Шаблон Провал. Пакет в шаблоне Провал содержит единственный вложенный пакет, а ограниченная версия пакета имеет тип "тихий". Такой пакет должен быть расширен для получения более детальной информации. Примеры пакетов с шаблоном Провал показаны на рисунке ниже:
» 0 0 О •
о
Рис. 7. Примеры шаблона Провал Вся информация, предоставляемая пакетом с таким шаблонов — его имя. При расширении этого пакета архитектурная информация не теряется. Рекомендуется автоматическое расширение таких пакетов для получения более детальной информации о связях пакета.
Шаблон Автономный. Пакет с шаблоном Автономный содержит по меньшей мере один вложенный пакет-поставщик и не содержит не одного потребителя или гибридный пакет. Автономный пакет не зависит от других пакетов в рабочем множестве.
• • •
Рис. 8. Примеры шаблона Автономный Пакет с таким шаблоном не требует дальнейшего расширения. Существование пакетов с таким шаблоном связей — признак хорошего проектирования.
Шаблон Архипелаг. Архипелаг — пакет который содержит по меньшей мере три вложенных пакета, которые при рассмотрении их как расширенные пакеты, не зависят друг от друга.
Г.... • • • •
О О оо •
Рис. 8. Примеры шаблона Архипелаг Пакет с таким шаблоном не требует дальнейшего расширения. Поскольку вложенные в архипелаг пакеты независимы, то скорее всего архипелаг является вспомогательным пакетом для хранения несвязанных пакетов.
6. Заключение
В статье рассмотрен подход к извлечению архитектуры программной системы, основанный на автоматическом распознавании в программной системе шаблонов пакетов языка Java. Данные шаблоны распознаются с использованием метрик оценивающих связей между пакетами. Данный подход применим как при интерактивной оценки архитектуры по автоматически генерируемых архитектурным видам системы, для и при автоматической генерации отчетов об архитектуре программной системы разработанной на языке Java.
Литература
1. Романов В.Ю. Инструмент обратного проектирования и рефакторинга программного обеспечения написанного на языке Java //International Journal of Open Information Technologies. — 2013. — Т. 1. — №. 8. — С. 1-6
2. L. Bass, P. Clements, and R. Kazman. Software Architecture in Practice, 2/E. Addison Wesley Professional, 2003.
3. G. Murphy, D. Notkin, and K. Sullivan. Software reflexion models: Bridging the gap between source and high-level models. In Proceedings of SIGSOFT '95, Third ACM SIGSOFT Symposium on the Foundations of Software Engineering, pages 18-28. ACM Press, 1995.
4. M.-A. D. Storey, K.Wong, F. D. Fracchia, and H. A. Mueller On integrating visualization techniques for effective software exploration. In INFOVIS '97: Proceedings of the 1997 IEEE Symposium on Information Visualization (InfoVis '97), page 38, Washington, DC, USA, 1997. IEEE Computer Society.
5. H. A. Muller and K. Klashinsky. Rigi — a system for programming-in-the-large. In Proceedings of the 10th International Conference on Software Engineering, pages 80-86, Singapore, 1988. IEEE Computer Society Press.
6. M. Lungu, A. Kuhn, T. Girba, and M. Lanza. Interactive exploration of semantic clusters. In Proceedings of VISSOFT 2005 (3rd IEEE International Workshop on Visualizing Software For Understanding and Analysis), pages 95-100. IEEE CS Press, 2005.
7. ISO/IEC/IEEE 42010:2011, Systems and software engineering — Architecture description, http://www.iso-architecture.org/ieee-1471/ 8
8. Nick Rozanski, Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, Second Edition, Addison-Wesley Professional, October 25, 2011, ISBN 978-0-32171833-4
9. Paul Clements; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Paulo Merson; Robert Nord; Judith Stafford, Documenting Software Architectures: Views and Beyond, Second Edition Publisher: Addison-Wesley Professional, October 05, 2010, ISBN 978-0-321-55268-6
10. Object Management Group, UML 2.4 Superstructure Specification, OMG document. http://www.omg.org/spec/UML/2A1/
