CC BY
59
ISSN 0321-2653 ИЗВЕСТИЯ ВУЗОВ. СЕВЕРО-КАВКАЗСКИИ РЕГИОН._ТЕХНИЧЕСКИЕ НАУКИ. 2017. № 3
ISSN 0321-2653 IZVESTIYA VUZOV. SEVERO-KAVKAZSKIIREGION. TECHNICAL SCIENCE. 2017. No 3
УДК 004.4 DOI: 10.17213/0321-2653-2017-3-29-34
ПОИСК И АНАЛИЗ СКВОЗНЫХ ФУНКЦИОНАЛЬНОСТЕЙ В РАЗМЕЧЕННОЙ ГРАММАТИКЕ ЯЗЫКА ПРОГРАММИРОВАНИЯ
© 2017 г. А.В. Головешкин
Южный федеральный университет, г. Ростов-на-Дону, Россия
SEARCHING AND ANALYSING CROSSCUTTING CONCERNS IN MARKED UP PROGRAMMING LANGUAGE GRAMMAR
A.V. Goloveshkin
Southern Federal University, Rostov-on-Don, Russia
Головешкин Алексей Валерьевич - аспирант, кафедра Goloveshkin Alexey Valeryevich - post-graduate student,
«Алгебра и дискретная математика», Институт математики, dePartment «Algebra and terete ma^e^ti^» Ы. V°rovich
механики и компьютерных наук имени И.И. Воровича, Institute °f M^^ti^ M^bm^ and C°mputer Stirn^
Южный федеральный университет, г. Ростов-на-Дону, Southern Federal Штете^ R^ot-0^0^ Russia.
Россия. E-mail: [email protected] E-mail: [email protected]
Сквозной функционал (crosscutting concern) ортогонален существующему разбиению программного кода на единицы модульности. Составляющие сквозной функционал участки кода логически связаны, но физически разбросаны по различным файлам, классам, методам. Разметка кода и построение модели размеченной программы позволяют ускорить процесс разработки и уменьшить его подверженность ошибкам за счёт анализа зависимостей между выделенными функциональностями.
В работе анализируется понятие сквозного функционала программы, рассматривается формальная модель, пригодная для его представления и анализа, демонстрируется её адаптация и применение для анализа сквозной функциональности в грамматике языка программирования.
Ключевые слова: сквозная функциональность; прорезающая функциональность; спутанный код; распределённый код; приоритетная декомпозиция; аспект; аспектно-ориентированное программирование; разметка кода; метрики прорезания; формальная грамматика; компилятор.
Crosscutting concern is orthogonal to existing dominant decomposition of a program. It consists of logically interconnected code fragments, spread out across multiple project files, classes and class methods. Concerns markup and building a program model allow to speed up the development process and reduce its error-proneness.
The paper considers the definition of crosscutting, describes the formal model applicable for crosscutting concerns representation and analysis and introduces the adaptation of the model to formal grammar investigation. The experiments demonstrate the application of the model to crosscutting concerns search and analysis in programming language formal grammar.
Keywords: crosscutting concern; scattering, tangling; dominant decomposition; aspect; aspect-oriented programming; concern markup; crosscutting metrics; formal grammar; compiler.
и теоретические основы
Введение. Терминология ты рассредоточены по различным элементам
приоритетной декомпозиции - разбиения программы на единицы модульности, зафиксирован-Функциональность (concern) - проблема, ного на этапе проектирования [1], - функцио-решаемая совокупностью фрагментов кода, и нальность называется сквозной или прорезаю-сама эта совокупность. В случае, если фрагмен- щей (crosscutting) [2].
ISSN 0321-2653 IZVESTIYA VUZOV. SEVERO-KAVKAZSKIIREGION.
По отношению к понятию «аспект» - базовому понятию парадигмы аспектно-ориентиро-ванного программирования (АОП) - понятие «прорезающая функциональность» является объемлющим. Ключевой идеей АОП является идея разделения кода аспекта, инкапсулирующего рассредоточенные действия, и основной программы [3]. Понятие прорезающей функциональности не содержит предположений о возможности её вынесения в отдельную единицу модульности, таким образом, оно охватывает как типовые случаи применения аспектно-ориенти-рованного программирования (логирование, проверка прав доступа и т.п.), так и более сложные ситуации, в которых фрагменты, составляющие сквозную функциональность, сильно связаны с остальным кодом и не могут быть исключены из него.
Понятие прорезающей функциональности, как и основные положения парадигмы АОП, восходит к идеям, высказанным в монографии А.Л. Фуксмана [4]: хотя в программе существует зафиксированный на этапе проектирования набор реализующих функций - горизонтальные слои, представленные непрерывными последовательностями текста, - в ней также можно выделить слои вертикальные, фрагментарно представленные в горизонтальных. В этом заключается двумерная структура программы [5]. Для изучения прорезающих функциональностей и их взаимодействия необходимо наличие сосредоточенного описания вертикального слоя или послойная разметка интегрированной программы.
Постановка задачи
Сквозная функциональность, присутствующая в компиляторе, непригодна для представления в виде аспекта. Новая конструкция, добавляемая в компилируемый язык, прорезает фазы компиляции, образующие приоритетную декомпозицию: добавляет и модифицирует правила разбора и преобразования текста программы в промежуточное и конечное представление, семантические проверки и оптимизации. Однако оформление языковых конструкций в виде аспектов затруднительно и усложняет восприятие разрабатываемого языка как единого целого. Между тем о них можно говорить как о функ-циональностях языка и компилятора. Их разметка и анализ взаимосвязей способны ускорить разработку и уменьшить количество допускаемых ошибок, причём данный анализ желательно осуществлять не только на уровне компилятора
TECHNICAL SCIENCE. 2017. No 3
как программы, но и на уровне грамматики разрабатываемого языка программирования.
Разметка и анализ функциональностей предполагают выстраивание инструментальным комплексом некоторой модели анализируемой программы. Эта модель должна обеспечивать не только качественный анализ функционально-стей, но и количественную оценку их взаимосвязей. Для решения схожей задачи для грамматики модель должна быть достаточно общей: применимой не только для ООП-программы, но и для произвольного структурированного текста.
В данной работе проводится анализ сквозных функциональностей в грамматике языка программирования. Ниже подробно анализируется модель, которая может быть использована как база при решении данной задачи. Приводится пример её практического применения.
Формализация сквозной функциональности
Формальное описание сквозной функциональности
В исследованиях [6, 7] предложена наиболее общая формализация для представления и анализа сквозной функциональности. В рассмотрение вводятся два множества: S - множество функциональностей, выделяемых в программе, и T - множество элементов программы для некоторой степени детализации (например, классов или методов). Определяются отображение f.S^2T, связывающее функциональность со множеством реализующих её элементов, и отображение g.T^2S, связывающее элемент со всеми функциональностями, в реализации которых он участвует.
На рис. 1 изображены два непрерывных участка кода программы, фрагменты которых вовлечены в реализацию одной или нескольких функциональностей. Масштаб фрагмента, задающего элемент множества T рассматриваемой формальной модели, определяется возможностями инструментального комплекса, применяемого для разметки кода. В случае с ООП-программой минимальным выделяемым фрагментом можно считать метод класса. Для формальной грамматики языка, описанной в виде форм Бэкуса-Наура, таковым фрагментом может быть альтернатива правила, определяющего нетерминальный символ, или, при использовании менее точного инструмента, правило целиком.
ISSN 0321-2653 IZVESTIYA VUZOV. SEVERO-KAVKAZSKII REGION.
TECHNICAL SCIENCE.
2017. No 3
Для данного примера S={ 1,2,3},
T={A,B,C,D,E}, f(1)={AAAE}, f(2)={B}, f^^DE}, g(A)={1}, g(B)={1,2}, g(C)={3} и т.д.
Рис. 1. Пример прорезающих функциональностей / Fig. 1. Example of crosscutting concerns
Прорезающий функционал определяется через сочетание распределенности (scattering) и спутанности (tangling). Функциональность 5 называется распределённой, если реализуется более чем одним элементом. Элемент t называется спутанным, если участвует в реализации нескольких функциональностей. Для sb S2eSs Ф S2 прорезание функционалом S1 функционала S2 имеет место тогда и только тогда, когда одновременно выполняются условия:
Ы1>1, atef*): S2Sg(t).
Трактовка прорезания как отношения, связывающего две функциональности, не противоречит введённому в настоящей работе определению сквозного функционала как прорезающего приоритетную декомпозицию. Каждый из элементов декомпозиции инкапсулирует функциональность, признанную на этапе проектирования более приоритетной, чем сквозная. Следовательно, прорезание приоритетной декомпозиции равносильно прорезанию заключённых в ней функциональностей.
Допускается учёт как непосредственных, так и опосредованных связей функциональности с элементами программы. Непосредственно связанные элементы реализуют основную логику функциональности; при ручной разметке кода непосредственно связанными элементами можно считать те, что были помечены разработчиком. Опосредованная связь элемента t и функциональности s означает, что существует элемент t, непосредственно связанный с S и некоторым образом зависящий от t. Суть данной зависимости для конкретной задачи определяется природой множества T . Если t и t - символы грамматики, под зависимостью можно понимать наличие символа t в правиле, определяющем t.
Поиск и анализ сквозных функциональностей
Выявить и проанализировать прорезающий функционал предлагается путём построения матриц специального вида. Первой строится матрица зависимостей dM: её строки соответствуют элементам множества S, столбцы - элементам множества T. Положим |s|= n, \t\= m. Единица на пересечении строки i, i е[1...и] и столбца j, j e[1...m] стоит в том случае, если tj е fSi), т.е. если элемент t участвует в реализации функциональности Si. Матрица dM для примера на рисунке представлена в табл. 1.
Таблица 1 / Table 1 Матрица зависимостей (dM) / Dependency matrix (dM)
A B C D E
1 1 1 0 1 1
2 0 1 0 0 0
3 0 0 1 1 1
Матрица сквозного функционала ccM (табл. 2) получается как произведение двух модификаций матрицы зависимостей. Ноль на пересечении i-й строки и j-го столбца означает, что j-й функционал не прорезается i-м, ненулевое значение равно количеству элементов, спутанных между функциональностями Si и Sj. Значения элементов на диагонали для распределённых функциональностей равны общему количеству реализующих их элементов, спутанных с другими функциональностями.
Таблица 2 / Table 2
Матрица сквозного функционала (ссМ) / Crosscutting matrix (ссМ)
1 2 3
1 3 1 2
2 0 0 0
3 2 0 2
Иногда в качестве матрицы сквозной функциональности удобнее рассматривать матрицу ссМ , получаемую из ссМ путём обнуления элементов на главной диагонали и замены всех остальных элементов, значение которых превышает единицу, на 1. Таким образом, в матрице для пары функциональностей остаётся только информация о том, прорезают ли они друг друга в принципе.
ISSN 0321-2653 IZVESTIYA VUZOV. SEVERO-KAVKAZSKIIREGION.
TECHNICAL SCIENCE. 2017. No 3
В качестве абсолютной величины, позволяющей оценить масштаб прорезания функциональностью sj других функциональностей системы, в работе [8] предлагается метрика Степень прорезания (СП), определяемая следующим образом:
ccM„ + £ И ■„
^= IS + II
Эксперименты
Рассмотренная модель была применена для анализа сквозных функциональностей в грамматике языка PascalABC.NET. При помощи интегрированной среды YACC MC [9], предназначенной для работы с грамматиками в формате генератора компиляторов GPPG [10], разработчиками языка было размечено 20 функционально-стей, существенных для процесса разработки. В табл. 3 представлен их неполный перечень, для каждой функциональности указано суммарное количество отнесённых к ней терминальных и нетерминальных символов.
Таблица 3 / Table 3
Функциональности грамматики PascalABC.NET и количество помеченных символов / PascalABC.NET grammar concerns and number of marked up symbols
Функциональность Кол-во
Выражения 32
Списки 50
Константы 15
Конст. выражения 20
Операторы 20
Лямбды 15
Кортежи 2
ShortFuncDefinition 3
func name 4
Проблема с атрибутами 6
Первичный анализ полученных данных показал, что функциональности, выделяемые в ходе реального процесса разработки, являются разнородными по масштабу и содержанию. Ряд функциональностей («Выражения», «Списки» и т.п.) связаны с реализацией конкретных языковых конструкций, в то время как более мелкие функциональности со специфическими именами («ShortFuncDefíшtюn», «func_name», «Проблема с атрибутами»), по всей видимости, представляют собой «рабочие множества» - множества символов грамматики, между которыми разработчику нужно было активно перемещаться при решении конкретной задачи. Функциональности, относящиеся к конструкциям языка, также
различаются по масштабу и могут быть вложенными.
В связи с большим количеством выделенных функциональностей и их разнородностью применение метрики СП, характеризующей про-резание одной функциональностью сразу всех прочих функциональностей системы, было признано нецелесообразным для рассматриваемой задачи. В ходе реального процесса разработки чаще всего ставится вопрос о том, как прорезают друг друга конкретные пары функциональностей грамматики. При модификации или отключении некорректно компилируемой языковой конструкции важно проверить, что данное действие не нарушит работу позднее реализованных функ-циональностей; также проверка взаимного про-резания важна, если несколько разработчиков параллельно модифицируют несколько функ-циональностей. После построения матрицы ссМ степени взаимного прорезания для пар функцио-нальностей были посчитаны при помощи метрики Попарная степень прорезания (ПСП) — естественным образом адаптированной автором настоящей работы метрики СП:
ссЫи
пспог, )=--ч—г.
Данная адаптация является симметричной, её значения лежат в диапазоне [0,1]: значение 0 достигается, если функциональности и Я] не прорезают друг друга, значение 1 означает, что множества связанных с ними элементов совпадают.
На первом этапе анализа учитывались только непосредственно связанные с функцио-нальностями символы грамматики: символы, помеченные разработчиками. На втором этапе к рассмотрению были добавлены опосредованные связи. В грамматике символ полагается опосредованно связанным с функциональностью, если участвует в правиле, определяющем символ, связанный с этой функциональностью непосредственно. На заключительном шаге для каждой функциональности множества непосредственно и опосредованно связанных элементов были объединены.
Обозначим через Н(я) и О(я) соответственно множества элементов, непосредственно и опосредованно связанных с некоторой функциональностью я, объединение этих множеств будем обозначать как (НиО)(я). Данные о количестве элементов, составляющих множества Н и О для ряда функциональностей, приведены в табл. 4.
ISSN 0321-2653 IZVESTIYA VUZOV. SEVERO-KAVKAZSKIIREGION.
TECHNICAL SCIENCE. 2017. No 3
Таблица 4 / Table 4
Количество элементов, непосредственно и опосредованно связанных с конструкциями языка / Number of elements directly and indirectly connected with language constructions
s H(s) O(s) H(s) U O(s)
Списки 50 84 96
Кортежи 2 15 17
Лямбды 15 49 52
В табл. 5 для этих функциональностей представлены значения метрики ПСП, столбцы соответствуют каждому из трёх описанных этапов анализа, в скобках рядом со значениями метрики приведено количество спутанных элементов - элементов, связанных с обеими функциональностями.
Таблица 5 / Table 5 ПСП^, s2) и количество спутанных элементов / PairwiseDegreeOfCrosscutting (s1, s2) and number of tangled elements
Si, S2 H(si)HH(s2) O(si)HO(s2) (HUO)(s1)n(HUO)(s2)
Списки, Кортежи 0 (0) 0,0421 (4) 0,0367 (4)
Лямбды, Кортежи 0 (0) 0,1636 (9) 0,1897 (11)
Списки, Лямбды 0,0156 (1) 0,0726 (9) 0,0725 (10)
но не позволяет определить её направление. Также возможен вариант, когда для двух функ-циональностей имеет место спутанность на уровне вспомогательных символов грамматики («сервисных функций»), каждый из которых к конкретной функциональности не относится. В этом случае модификацию функциональностей можно осуществлять без дополнительных мер предосторожности, однако метрика ПСП всё равно показывает наличие зависимости. Предположительно, такова связь функциональностей «Списки» и «Кортежи», где количество спутанных опосредованно связанных элементов (второй столбец) равняется количеству спутанных элементов, посчитанному после объединения множеств H и o. Однако подобная картина может наблюдаться и в случае, когда элемент, опосредованно связанный с обеими функционально-стями, связан с одной из них непосредственно.
Для преодоления недостатков метрики ПСП автором настоящей работы вводится метрика Степень зависимости (сз):
C3(s, Sj ) =
|я(л,.)П(яиох^.)|
Сложность модификации и отключения зависит от количества спутанных элементов разного типа для пар функциональностей. Однако данные табл. 5 позволяют однозначно выявить только одну из нескольких возможных ситуаций: если функциональности спутаны своими непосредственно связанными элементами, изменение любой из них может повлиять на другую. Данная ситуация имеет место для функциональностей «Списки» и «Лямбды». Если непустое пересечение впервые возникает при добавлении к рассмотрению опосредованно связанных элементов, допустимы две трактовки. Элемент, непосредственно связанный с одной функциональностью, может быть опосредованно связан с другой, в этом случае зависимость есть, но она не симметрична: изменения второй функциональности не влияют на первую. Очевидно, данное утверждение справедливо для пары «Лямбды» и «Кортежи», где количество спутанных элементов в последнем столбце превышает сумму количеств элементов, связанных с обеими функционально-стями только непосредственно (первый столбец) и только опосредованно (второй столбец). Метрика ПСП позволяет обнаружить зависимость,
Значение 0 означает, что функциональность sj может быть отключена без нарушения работы Sj; чем ближе значение метрики к 1, тем большая часть элементов sj спутана с Sj и тем сложнее осуществить модификацию или отключение. Результаты подсчёта данной метрики для функциональностей, представленных в табл. 4, приведены в табл. 6.
Таблица 6 / Table 6
Значения степеней зависимости для рассматриваемых функциональностей / Degree of dependency values for concerns considered
S1, S2 СЗ^, s2) СЗ^2, so
Списки, Кортежи 0 0
Лямбды, Кортежи 0,2 0,5
Списки, Лямбды 0,04 0,27
Как можно заметить, взаимозависимость функциональностей «Списки» и «Кортежи», поставленная под сомнение ранее, действительно отсутствует, имеет место только спутанность на уровне сервисных функций: метрика СЗ для данной пары принимает нулевое значение.
На практике значение метрики СЗ следует учитывать совместно с информацией об общем количестве элементов, непосредственно реализующих анализируемые функциональности, поскольку одно и то же значение СЗ для
ISSN 0321-2653 IZVESTIYA VUZOV. SEVERO-KAVKAZSKIIREGION.
функциональностей разного масштаба означает различные по сложности ситуации, складывающиеся в процессе разработки.
Заключение
Разметка программы и применение обобщённой формальной модели позволяют рассмотреть прорезающие функциональности независимо от применимости к ним АОП. В частности, такое рассмотрение становится возможным для грамматик языков программирования. Информация о существующих функциональностях может быть получена из разметки грамматики, при этом важно учитывать элементы как непосредственно помеченные разработчиками, так и связанные с функциональностями опосредованно. Количественная оценка и качественный анализ прореза-ния функциональностями друг друга позволяют оценить влияние модификации и отключения функциональности на прорезаемые ею, что, в свою очередь, позволяет скорректировать дальнейший процесс разработки.
Литература
1. Kienzle J., Yu Y., Xiong J. On Composition and Reuse of Aspects. // University of Central Florida. URL:
TECHNICAL SCIENCE. 2017. No 3
http://www.eecs.ucf.edu/leavens/FOAL/papers-2003/kienzle-yu-xiong.pdf (дата обращения: 15.12.2016).
2. Kaindl H. What is an Aspect in Aspect-oriented Requirements Engineering // Proceedings of the 13th International Workshop on Exploring Modeling Methods for Systems Analysis and Design, Montpellier, France, June 16 - 17, 2008. P. 164 - 170.
3. Masuhara H., Kiczales G. Modeling Crosscutting in Aspect-
Oriented Mechanisms. // Object-Oriented Programming, ser. LNCS. 2003. Vol. 2743. P. 2 - 28.
4. Фуксман А.Л. Технологические аспекты создания программных систем. М.: Статистика, 1979. 184 с.
5. Горбунов-Посадов М.М. Как растёт программа // Открытые системы. 2000. № 10. С. 43 - 47.
6. Conejero J.M., Hernández J., Jurado E., Berg K.G., van den. Crosscutting, what is and what is not?: A Formal definition based on a Crosscutting Pattern // University of Twente. URL: http://doc.utwente.nl/64648/1/ConHerJurBer2007.pdf (дата обращения: 25.11.2016).
7. Berg K.G. van den, Conejero, J.M., Hernández J. Identification of Crosscutting in Software Design. // 8th International Workshop on Aspect-Oriented Modeling. Bonn, Germany, March 2006. P. 1 - 7.
8. Conejero J.M., Figueiredo E., Garcia A., Hernández J., Jurado E. Early Crosscutting Metrics as Predictors of Software Instability. // Objects, Components, Models and Patterns, ser. LNBIP. 2009. Vol. 33. P. 136 - 156.
9. Головешкин А.В. IDE с аспектной разметкой кода для работы с YACC-грамматиками: магистерская дис. Южный федеральный университет, Ростов н/Д., 2015.
10. The GPPG Parser Generator. Documentation // CodePlex. Gardens Point Parser Generator. URL: http://gppg.codeplex.com/downloads/get/378046 (дата обращения: 20.12.2016).
References
1. Kienzle J., Yu Y., Xiong J. On Composition and Reuse of Aspects. // University of Central Florida. Available at: http://www.eecs.ucf.edu/leavens/FOAL/papers-2003/kienzle-yu-xiong.pdf (accessed 15.12.2016)
2. Kaindl H. What is an Aspect in Aspect-oriented Requirements Engineering // Proceedings of the 13th International Workshop on Exploring Modeling Methods for Systems Analysis and Design, Montpellier, France, June 16-17, 2008. Pp. 164-170.
3. Masuhara H., Kiczales G. Modeling Crosscutting in Aspect-Oriented Mechanisms. // Object-Oriented Programming, ser. LNCS. 2003. Vol. 2743, Pp. 2-28.
4. Fuksman A.L. Tekhnologicheskie aspekty sozdaniyaprogrammnykh system [Technological Aspects of Program Design]. Moscow, Statistika Publ., 1979, 184 p.
5. Gorbunov-Posadov M.M. Kak rastet programma [The way to grow a program]. Otkrytye sistemy = Open Systems Journal, 2000, no. 10, pp. 43-47. [In Russ.]
6. Conejero J.M., Hernández J., Jurado E., Berg K.G. van den. Crosscutting, what is and what is not? A Formal definition based on a Crosscutting Pattern. // University of Twente. Available at: http://doc.utwente.nl/64648/1/ConHerJurBer2007.pdf (accessed 25.11.2016)
7. Berg K.G. van den, Conejero, J.M., Hernández J. Identification of Crosscutting in Software Design. // 8th International Workshop on Aspect-Oriented Modeling. Bonn, Germany, March 2006. Pp. 1-7.
8. Conejero J.M., Figueiredo E., Garcia A., Hernández J., Jurado E. Early Crosscutting Metrics as Predictors of Software I nstability. // Objects, Components, Models and Patterns, ser. LNBIP. 2009. Vol. 33, Pp. 136-156.
9. Goloveshkin A.V. IDE s aspektnoi razmetkoi koda dlya raboty s YACC-grammatikami. Magisterskaya diss. [IDE with aspect grammar markup for YACC grammars development. Master's dissertation]. Rostov-on-Don, Yuzhnyi federal'nyi universitet, 2015.
10. The GPPG Parser Generator. Documentation. // CodePlex. Gardens Point Parser Generator. Available at: http://gppg.codeplex.com/downloads/get/378046 (accessed 20.12.2016)
Поступила в редакцию /Received_03 мая 2017 г. /May 03, 2017
