Как отмечают авторы [16], в то время как существует поддерживающий АО- концепции язык программирования AspectJ [5], отсутствует реализованный язык моделирования, поддерживающий проектирование AspectJ-программ. Предложениям по разработке подобного языка посвящено большое количество работ, представленных на различных конференциях в 1998-2002 гг.
Подавляющее большинство исследователей предлагают основываться на существующем стандарте UML [2] и применить существующие в нем механизмы расширения графической нотации сущностей и отношений (стереотипы, ограничения, помеченные значения) для описания дополнительных концепций AO-проектирования.
Так, в работе [15] предлагается ввести три новых концепции: группы (для целей классификации гетерогенных и распределенных сущностей), пересекающие отношения (позволяющие программисту определить “точки пересечения” аспекта с функциональной программой), аспектные классы (реализующие расширения программы в точках пересечения). Графически это предполагает использование имеющихся в UML элементов: классов и ассоциаций с добавлением стереотипов “group”, “pointcut”, “aspect”. Для методов аспектного класса вводятся стереотипы “before”, “after”, “around”, описывающие момент их вызова по отношению к вызову “пересекаемых” функций, а также предлагается набор правил определения и интерпретации семантики ролей и кратностей для пересекающих отношений.
В [12] рассматривается выделение аспектов в программной системе. Примеры диаграмм в этой работе похожи на приводимые в [15]: аспект рассматривается как диспетчер взаимодействия двух взаимозависимых классов и других, предоставляющих некоторую функциональность. Но, в отличие от [15], в модель явно вводится понятие “точки пересечения”, которую предлагается моделировать как вариант класса, а не как вариант ассоциации, более подробно рассмотрены “точки соединения” – места взаимодействия с аспектом, прерывания/возобновления выполнения основной программы. “Точки соединения могут быть объединены для построения интерфейса аспекта, также как множество интерфейсов в UML могут быть объединены в форму интерфейса класса”. Вводится понятие парных (conjugated) точек соединения, в которых происходит вызов методов с одинаковыми сигнатурами, но направления потока управления противоположны (в которых управление передается аспекту и возвращается им).
С. Кларк и Р. Уолкер предлагают свой вариант нотации [8] для описания аспектов средствами UML. Они предлагают использовать параметризируемые пакеты (что само по себе является непредусмотренным расширением UML) со стереотипом “subject”, поскольку в принципе рассматривают аспекты как элементы субъектно-ориентированного проекта. Внутри пакета могут быть размещены диаграммы классов и взаимодействия, что позволяет графически показать поведение программы после связывания. Такой пакет является в терминологии авторов “композиционным шаблоном”. При этом, “параметризируя проектный субъект и обеспечивая механизм для привязки этих параметров к элементам модели в других проектных субъектах, мы можем определить композицию пересекающего поведения с основным проектом способом, допускающим повторное использование”. Предлагаемая семантика (отношение композиции, расширяемое строкой bind) оперирует классами и методами связываемых субъектов.
В [16] авторы рассматривают моделирование “пересекающих эффектов” отдельно в структуре типов и в поведении некоторой системы. Оригинальность их подхода заключается в предложении использовать параметризируемые, помеченные стереотипом “introduction” кооперации для определении свойств (атрибутов, операций) и отношений каждого из “пересечений” аспектных и обычных классов. Параметр кооперации используется для определения правил связывания (фактически – инстанцирования кооперации и ее встраивания в существующую систему классов). Помимо этих коопераций, в аспектных классах вводятся, независимо от методов, элементы со стереотипами “pointcut” и “advice”: “точки пересечения” и “извещения”, определяющие пересечение логики аспекта и программной системы, и вводящие механизм перехвата управления. Предложенная нотация базируется на концепциях языка AspectJ, но является излишне усложненной.
Разработчики UML указывают, что “На практике для именования класса используют одно или несколько коротких существительных, взятых из словаря моделируемой системы” [2]. Аналогично, в большинстве рассмотренных работ имя аспектного класса является наречием и показывает выполняемую операцию.
Помимо рассмотренных выше четырех работ, предлагающих проработанные, готовые к практическому применению графические нотации, доступно большое количество статей теоретической направленности. Так, в [4] делается попытка формализовать использование средств расширений UML для специфицирования понятий АО-методологии. Для этого используется понятие “профиля” UML – механизма, позволяющего описать правила использования средств расширения языка в некоторой предметной области. Расширяя метамодель UML, авторы определяют набор стереотипов и их приложение к таким элементам метамодели, как класс и ассоциация. Авторы [17] также предлагают расширить метамодель UML для описания аспектных классов и отношений, но основной акцент сделан на предложении основанного на правилах XML языка разметки для описания проектных моделей, в частности, содержащих аспекты. Выгоды его введения обосновываются необходимостью наличия “нейтрального по отношению к приложениям формата” для коммуникации между разработчиками, облегчением повторного использования описаний аспектов, а также их разделением между различными средствами проектирования, связывания, кодогенерации. Комплексным подходом отличается статья известных разработчиков из IBM У. Харрисона, П. Терра и Г. Оссхера [9], в которой они рассматривают способы, какими информация об аспектах может быть отражена на различных диаграммах UML. Здесь же следует упомянуть работы С. Кларк [6, 7], в которых она “представляет подход к разработке систем, базирующийся на объектно-ориентированной модели, но расширяющий ее добавлением новых возможностей декомпозиции”. В докладе [10] представлен прототип автоматизированного средства для преобразования высокоуровневых моделей UML, поддерживающих абстракции АОП, к низкоуровневым детализированным моделям, по которым может быть сгенерирован программный код, т.е. предложено проводить связывание на уровне моделей.
Целью следующей части настоящей статьи является дать представление о применимости АО-методов в обработке информационных потоков в объектно-ориентированной среде, вариантом реализации которой является объектная (объектно-иерархическая) база данных программного комплекса диспетчерского пункта (ДП) АСУТП. При составлении диаграмм мы будем придерживаться нотации, предложенной в [15].