WWW.DISS.SELUK.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА
(Авторефераты, диссертации, методички, учебные программы, монографии)

 

Pages:   || 2 | 3 |

«В. О. Сафонов АСПЕКТНО-ОРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ Учебное пособие Рекомендовано УМО в области инновационных междисциплинарных общеобразовательных программ в качестве учебного пособия ...»

-- [ Страница 1 ] --

САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

В. О. Сафонов

АСПЕКТНО-ОРИЕНТИРОВАННОЕ

ПРОГРАММИРОВАНИЕ

Учебное пособие

Рекомендовано УМО в области инновационных междисциплинарных

общеобразовательных программ в качестве учебного пособия

по специальности 01.05.03 — математическое обеспечение

и администрирование информационных систем С.-ПЕТЕРБУРГ 2011 УДК 004.4’2 ББК 32.811.7 С22 Печатается по постановлению Редакционно-издательского совета математико-механического факультета С.-Петербургского государственного университета Сафонов В. О.

С22 Аспектно-ориентированное программирование: учеб. пособие. — СПб.: Изд-во С.-Петерб. ун-та, 2011. — 104 с.

ISBN 978-5-288-05188- Учебное пособие знакомит читателей с основами нового перспективного подхода к разработке программ — аспектно-ориентированным программированием (АОП), предназначенного для модуляризации и автоматизированного добавления (weaving) в целевые приложения сквозной функциональности, например, добавления в код целевой программы проверок безопасности, трассировки, действий по защите информации. АОП в настоящее время играет все более важную роль при разработке и модернизации современного программного обеспечения — прежде всего, для организации надежных и безопасных вычислений (trustworthy computing). В учебном пособии дан обзор концепций, методов и инструментов АОП и подробно описан разработанный под руководством автора современный инструмент АОП — система Aspect.NET, получившая широкое признание и используемая в 26 странах мира. Даны примеры аспектов и целевых приложений и практические рекомендации по использованию системы Aspect.NET. Автор учебного пособия и системы Aspect.NET — широко известный в России и в мире специалист в области информатики и инженерии программ.

Издание предназначено для студентов старших курсов и аспирантов, обучающихся на специальностях, связанных с обработкой информации, а также специалистов в области информатики.

ББК 32.811. © В. О. Сафонов, © Санкт-Петербургский государственный университет, ISBN 978-2-288-05188-

ВВЕДЕНИЕ





Данное учебное пособие посвящено аспектно-ориентированному программированию (АОП) [1] — новому перспективному направлению развития программирования, которое сложилось в середине 1990-х гг., но истоки которого были заложены гораздо раньше, еще в 1970-х — 1980-х гг.

АОП — один из современных подходов к программированию, который существенно дополняет возможности широко используемого ныне, вот уже более 40 лет, объектно-ориентированного программирования (ООП).

Современной и актуальной технологии и платформе ООП, Javaтехнологии, посвящена предыдущая книга автора [2].

Данное учебное пособие, по-видимому, является первой книгой по АОП на русском языке. В книге изложены в доступной для изучения форме принципы АОП, архитектура инструментальных средств АОП, в том числе — разработанный под руководством автора инструментарий АОП Aspect.NET [3], используемый в 26 странах мира. Рассмотрено применение АОП для решения различных задач — организации надежных и безопасных вычислений (trustworthy computing), контрактного проектирования (design by contract). Намечены перспективы развития и дальнейшего, все более широкого использования АОП и системы Aspect.NET.

К каждой главе книги даны контрольные вопросы для самопроверки (или проведения опроса студентов) и упражнения для самостоятельной работы. Это позволяет использовать книгу как основу для факультативного односеместрового спецкурса, спецсеминара или практических занятий (hand-on labs) для студентов ИТ-специальностей.

Рекомендуется использование книги для студентов старших курсов — с третьего по пятый (шестой), владеющих одним или несколькими языками программирования и основами технологии.NET и языка C#.

Книга основана на многолетнем опыте автора в области ИТ — выполнения научно-исследовательских работ, промышленных проектов, международного сотрудничества в области разработки программного обеспечения, преподавания на математико-механическом факультета Санкт-Петербургского государственного университета. Основы АОП изложены в лекции 7 учебного курса автора «Архитектуры и модели программ и знаний» [4], опубликованном на академическом сайте Microsoft в 2009 г.

Автор является основателем и научным руководителем уникальной, первой в России и одной из ведущих в мире, научной школы по аспектно-ориентированному программированию, созданной на математико-механическом факультете СПбГУ. Автор выражает сердечную благодарность своим ученикам, участникам нашей научной школы по АОП: кандидатам физ.-мат. наук Дмитрию Григорьеву, Михаилу Грачеву, Руслану Муханову, аспирантам Анне Когай, Доану Нгуен Вану, Денису Подорожкину, Денису Фролову и многим другим — за оригинальные идеи в области АОП, реализацию системы Aspect.NET (автора — Дмитрий Григорьев и Михаил Грачев) и ее аналога для академической версии.NET — системы AspectRotor (автор — Руслан Муханов), реализацию библиотек аспектов для использования системы Aspect.NET в различных предметных областях (авторы — Анна Когай, Денис Подорожкин, Доан Нгуен Ван, Денис Фролов). Я благодарен также моим студентам, интересующимся АОП, в особенности — студентам-дипломникам Игорю Евдакову и Айбеку Саримбекову, реализовавшим в 2010 г. в качестве своих дипломных работ поддержку второго языка — Visual Basic — в системе Aspect.NET.





По аспектно-ориентированному программированию и системе Aspect.NET опубликована широко известная в мире монография автора [1] на английском языке в издательстве John Wiley & Sons (2008 г.) и целый ряд статей и учебных материалов на русском и английском языках [5–17], которые могут быть использованы для дальнейшего изучения АОП и методов его практического использования в современном программировании.

ПРЕДПОСЫЛКИ И ИСТОРИЯ АОП

1.1. АОП и сквозная функциональность Аспектно-ориентированное программирование (АОП) [1] — новый перспективный подход к разработке программ. Суть данного подхода — поддержка разработки и модификации сквозной функциональности (cross-cutting concerns) в больших программных системах.

При проектировании, реализации и модификации любой программы ее архитектура полностью или частично описывается в виде иерархии модулей — классов, процедур, функций, реализующих различные функциональные возможности (функциональности) программы. Простейшая из таких возможностей — например, вычисление какой-либо математической функции по известной формуле, — может быть реализована всего одним модулем в классическом смысле этого слова — функцией, процедурой, статическим методом, макросом, — имеющим, по терминологии Г. Майерса [18], функциональную прочность. Более сложная по семантике функциональность реализуется в виде иерархии классов, библиотеки функций и др. Такова, например, любая компонента большой программной системы, реализующая часть ее бизнес-логики, т. е. решающая конкретную задачу из прикладной области, — например, расчет зарплаты, расчет курсов акций, планирование распределения заданий между сотрудниками.

Такого рода функциональность в программе, реализация которой выразима в виде одного модуля или взаимосвязанной совокупности модулей, будем называть модульной функциональностью (modular concern).

Как показывает анализ архитектуры программных систем, существует также сквозная функциональность (cross-cutting concerns). Данное понятие объединяет такие виды функциональных возможностей, идей, принципов, методов, реализация которых принципиально не осуществима в виде лишь одной иерархии взаимосвязанных модулей, а, в дополнение к ним, требует вставки в физически рассредоточенные точки программы фрагментов нового кода (либо исполнения новых фрагментов кода в рассредоточенных точках целевой программы, без их явной вставки). Как правило, фрагменты кода, реализующие новую сквозную функциональность, являются исполняемыми конструкциями (операторами), чаще всего — вызовами, однако они могут быть и описаниями (определениями) данных, также являющихся частью реализации рассматриваемой сквозной функциональности.

1.2. Типичные классы задач, решаемые АОП Типичные классы задач, решение которых требует реализации сквозной функциональности, относятся к надежному и безопасному программированию (trustworthy computing) [1, 12]:

безопасность (security) — аутентификация пользователей и программ; авторизация (проверка полномочий кода или пользователя для выполнения тех или иных действий); криптографические операции над данными с целью обеспечения их конфиденциальности и т. д.;

надежность (reliability) — проверка выполнения предусловий и постусловий в модулях и инвариантов в классах; обработка ошибок и др.;

безопасность многопоточного выполнения кода (multithreaded safety) — синхронизация по ресурсам или по событиям, выделение критических участков кода, взаимное исключение доступа к ним и др.;

протоколирование и профилирование работы программы (logging and profiling) — трассировка начала и окончания выполнения каждой функции (каждого метода), вывод их аргументов и результатов, сбор и вывод статистической информации об исполнении различных фрагментов программы и т. д.

Для решения подобных задач — в особенности, в характерных ситуациях, когда система в целом уже разработана, и ставится задача улучшения ее безопасности и надежности, — необходимы весьма трудоемкие и небезопасные, с точки зрения вероятности внесения ошибок, групповые вставки и модификации кода, обеспечивающие добавление в программу требуемых функциональных возможностей. Например, вставка вызова операции закрытия семафора перед любой операцией, изменяющей некоторый глобальный ресурс, и вставка вызова парной ей операции открытия семафора после каждого изменения данного глобального ресурса.

Выполнение данной нетривиальной модификации существующей программной системы требует глобального анализа всего исходного кода программы, размер которого может составлять несколько десятков тысяч или даже несколько миллионов строк. Если подобные действия выполняются вручную, с использованием возможностей используемой при разработке универсальной интегрированной среды, например, Visual Studio.NET или Eclipse, но без применения каких-либо специализированных технологий и инструментов, — то весьма велик риск внесения в программу ошибок. Например, разработчик может вставить в код лишь вызов операции закрытия семафора, но по каким-либо причинам забыть вставить парную ей «синхронизирующую скобку» — вызов операции открытия семафора после модификации ресурса, что может привести к тупику (deadlock) при исполнении программы, который впоследствии весьма сложно обнаружить и устранить.

1.3. АОП и модульное программирование. Предыстория АОП Аспектно-ориентированное программирование (АОП) — один из новых подходов к программированию, предназначенный для модуляризации сквозной функциональности и ее автоматизированного, безопасного и надежного добавления в целевую программу, а также для поиска (локализации) и модификации в целевой программе некоторой уже реализованной сквозной функциональности.

АОП расширяет традиционную концепцию модуля по Майерсу [18] понятием аспекта (aspect). Аспект — это реализация сквозной функциональности, выполненная в виде специального модуля, содержащего фрагменты кода (действия аспекта), активируемые в заданных точках целевой программы как часть новой функциональности. Определение аспекта содержит также спецификацию разреза (pointcut) кода целевой программы — совокупности правил поиска в ней точек присоединения (join points) аспекта к целевой программе, для последующего применения (внедрения, weaving) в найденных точках действий аспекта (слово weave буквально означает ткать, плести). Внедрение аспекта — способ его использования как новой разновидности модуля, в отличие от традиционных модулей «по Майерсу», используемых путем их явного вызова.

Основатель АОП — Г. Кичалес (G. Kiczales), Университет Британской Колумбии, Канада [19], а наиболее популярный инструмент АОП для платформы Java — разработанная под его руководством система AspectJ [20], первая версия которой была создана в 1995 г. в фирме Xerox Palo Alto Research Corporation, США. Подробный обзор подходов к АОП и инструментов АОП приведен в монографии [1].

Для российских специалистов особенно важен тот факт, — как мне довелось убедиться, пока недостаточно известный современным специалистам по АОП в США и Канаде, — что подход к разработке программ, близкий к АОП, был предложен еще в конце 1970-х годов проф. А. Л. Фуксманом (Ростовский университет) [21] под названием технология рассредоточенных действий, сокращенно — РД-технология (другое название, использованное автором подхода, — технология вертикального слоения). Согласно данной технологии, вертикальный слой (срез) — совокупность рассредоточенных действий, фрагментов кода, реализующих некоторую расширяющую функцию, а процесс разработки и модификации программы представляет собой последовательность операций добавления или изменения расширяющих функций.

Даже при беглом изложении основных идей РД-технологии очевидно ее сходство с АОП. Более того, даже в самом названии монографии [21] присутствует слово аспект. К сожалению, РД-технология не получила своего коммерческого воплощения, но осталась в истории отечественного и мирового программирования пионерской идеей, преемственная связь АОП с которой несомненна.

В настоящее время АОП все шире распространяется среди программистов, — как в академической среде, так и в коммерческих фирмах, — во многом благодаря энтузиазму и активности разработчиков системы AspectJ и значительному влиянию этой новаторской системы на развитие и применение инноваций в области инженерии программ.

Ежегодно проводится конференция Aspect-Oriented Software Development [22]. Обучающие курсы (tutorials) и исследовательские доклады по АОП неизменно входят в программу широко известных в мире конференций в области ИТ, например, OOPSLA. Имеются сотни инструментов АОП для платформ Java и.NET, расширения средствами АОП языков программирования C, C++, JavaScript, PHP и многих других [1].

В России АОП пока недостаточно распространено, несмотря на то, что его концепции известны уже более 15 лет. Созданы русскоязычные страницы Web-энциклопедии Wikipedia и краткий wikiучебник по АОП на русском языке [23]. Литература по АОП на русском языке, как правило, ограничивается переводами и обзорами зарубежных работ [24]. Но уже (кроме работ нашей научной школы по АОП) появляются исследования молодых авторов, посвященные применению известных инструментов АОП (например, JBoss [25]) в различных областях — например, для разработки графических пользовательских интерфейсов [26]. Отечественная монография [27], посвященная методам расширения программ, определяет концепцию рассредоточенного набора, весьма близкую идеям технологии вертикального слоения и АОП.

Хотелось бы выразить надежду, что настоящая книга послужит более широкому распространению АОП в России, а также уточнению русскоязычной терминологии по АОП, насколько это возможно в настоящий момент: вследствие разнообразия подходов к АОП, даже англоязычную и, тем более, русскоязычную терминологию в столь новой области, как АОП, нельзя считать устоявшейся.

Вопросы к главе 1. Что такое аспектно-ориентированное программирование?

2. Что такое модульная и сквозная функциональность?

3. Приведите примеры типичных задач организации надежных и безопасных вычислений (trustworthy computing).

4. Почему использование традиционных интегрированных сред для вставки рассредоточенных действий в программу может оказаться ненадежным и привести к ошибкам? Приведите конкретный пример.

5. Что такое аспект?

6. Что такое поперечный разрез (pointcut)?

7. Что такое точка присоединения (join point)?

8. Что такое применение (внедрение) аспекта?

9. Кто был основателем АОП и какая система АОП была разработана под его руководством?

10. В чем основная идея технологии рассредоточенных действий (РДтехнологии) — предшественника АОП — и кто был ее автором?

11. Что такое вертикальный слой (срез) и какова родственная связь данной концепции с концепцией аспекта в АОП?

Упражнения к главе 1. Проанализируйте и сформулируйте отличия объектно-ориентированного программирования от аспектно-ориентированного программирования.

2. Скачайте и инсталлируйте инструмент АОП AspectJ, изучите его и пропустите прилагаемые к нему примеры целевых приложений и аспектов.

3. Скачайте и инсталлируйте инструмент АОП JBoss, изучите его и пропустите прилагаемые к нему примеры целевых приложений и аспектов.

4. Проанализируйте, является ли нарушением принципов модульного программирования по Майерсу вставка в класс дополнительного определения поля, которое видимо только извне использующему его аспекту.

ОСНОВНЫЕ КОНЦЕПЦИИ АОП

2.1. Подходы к концепциям АОП и к его реализации Согласно определению АОП в Wikipedia [23], «программные парадигмы аспектно-ориентированного программирования (АОП) и аспектно-ориентированной разработки программ (АОРП) предназначены для разделения функциональностей (separation of concerns), прежде всего — сквозных функциональностей (cross-cutting concerns), и являются расширением концепций модуляризации. АОП обеспечивает это преимущественно путем реализации расширений используемого языка программирования; АОРП использует сочетание языка, окружения и метода».

Авторы статьи по АОП в Wikipedia противопоставляют концепции АОП и АОРП. В частности, если буквально следовать классификации, предложенной в [23], то и AspectJ, и Aspect.NET относятся к инструментам АОРП, а не АОП. Однако в данной работе будем использовать единый, более распространенный термин АОП, чтобы не усложнять терминологию и обеспечить более общую точку знения на данный круг проблем. На наш взгляд, разделение на АОП и АОРП не вполне целесообразно — на данном этапе развития АОП объединение идей и усилий различных школ более важно, чем их противопоставление.

Таким образом, аспектно-ориентированное программирование (aspect-oriented programming) — это технология разработки сквозной функциональности (cross-cutting concern) в виде специализированных модулей — аспектов (aspects), с целью ее последующего внедрения (weaving) путем активизации фрагментов кода аспекта — действий (advices) в выделенных инструментом АОП в целевой программе точках присоединения (join points). Спецификация точек присоединения, задаваемая в определении аспекта либо в виде отдельного модуля, на который могут ссылаться различные аспекты, получила название разрез (pointcut). Чтобы пояснить суть решаемых проблем, рассмотрим типичную структуру современной программной системы (рис. 2.1).

Рис. 2.1. Типичная структура программной системы Как видно из схемы, программа состоит из совокупности реализаций модульных функциональностей (modular concerns) и сквозных функциональностей (crosscutting concerns), причем последние, — например, проверки безопасности, — реализованы в виде совокупностей рассредоточенных фрагментов (вставок) кода в различные модули программы. Реализация сквозных фунциональностей показана различными оттенками цвета. Таким образом, программная система представляет собой некий «слоеный пирог» из фрагментов реализации сквозных функциональностей.

Основная идея АОП проиллюстрирована на рис. 2.2:

Рис. 2.2. Разделение сквозных функциональностей в АОП АОП предлагает методы раздельного описания специальных модулей — аспектов, каждый из которых реализует некоторую сквозную функциональность (аспекты показаны справа), и инструменты для последующего применения аспектов в одном или нескольких целевых приложений.

По сути дела, аспект можно представлять себе как совокупность правил вида Условие - Действие, где Условие специфицирует разрез целевой программы, а Действие задает фрагмент кода, активизируемый в целевой программе при выполнении данного условия.

Процесс компоновки модулей в АОП изображен на рис. 2.3.

Рис. 2.3. Процесс компоновки модулей в АОП Помимо основной задачи реализации и внедрения новой сквозной функциональности, АОП решает две других не менее важных задачи:

аспектизация (aspectizing [5], aspect-oriented refactoring [28], aspect mining [29]) — выделение аспектов из не аспектно-ориентированных программ, с целью их последующего многократного использования;

модификация сквозной функциональности, представленной определением аспекта и всеми его внедрениями.

Спецификация (определение) аспекта в АОП может быть выполнена на специальном метаязыке АОП, как это делается, например, в нашей в системе Aspect.NET, — либо в терминах расширений базового языка программирования конструкциями АОП, как в системе AspectJ, которая по существу является реализацией аспектно-ориентированного расширения языка Java.

При использовании метаязыка АОП возникает проблема его отображения в базовый язык реализации, которая в Aspect.NET решается путем конвертирования конструкций метаязыка Aspect.NET.ML в определения введенных нами специализированных атрибутов АОП (custom attributes).

При втором подходе возникает зависимость инструмента АОП от базового языка и всех его изменений. Например, код на языке AspectJ требует для компиляции специализированного компилятора ajc, входящего в состав системы AspectJ, и при любом изменении базового языка Java приходится вносить соответствующие изменения в компилятор ajc.

Но самое существенное, с концептуальной точки зрения, в том, что при расширении базового языка средствами АОП традиционные для ООП понятия, конструкции и взаимосвязи (классы, поля, объекты, наследование) «сосуществуют» в одном расширенном языке с гораздо более общими по своей природе метапонятиями АОП (аспект, разрез, действие аспекта, внедрение, точка присоединения). При этом у пользователей возникает целый ряд проблем, которые можно охарактеризовать как «проблемы концептуальной путаницы» (conceptual confusion): могут ли аспекты наследоваться от классов, классы — от аспектов, как при этом изменяется семантика программы и т. д. Все это лишь затрудняет использование АОП, а не облегчает его, так как и без того непростой базовый язык реализации оказывается и вовсе запутанным, что может вообще оттолкнуть пользователей от освоения и использования АОП.

На наш взгляд, АОП и его концепции относятся к мета-уровню методологии программирования, спецификации программ и их трансформаций, — более высокому, чем уровень конкретных известных программных парадигм: процедурное, объектно-ориентированное, функциональное программирование и др. АОП решает в общем виде задачи трансформации программ с целью добавления или модификации в них сквозной функциональности, а также спецификации таких трансформаций. При этом методы и подходы, характерные для АОП, на наш взгляд, практически не зависят от концепций базового языка реализации. Хотя при описании разрезов и правил внедрения и используются понятия базового языка, но, по своей природе и семантике, суть преобразований, выполняемых в АОП, — например, вставка перед всеми вызовами модуля (в классическом смысле) с заданным именем некоторого нового кода, — не зависит от базового языка реализации и воплощенной в нем парадигмы. Для процедурных языков Фортран, Паскаль и Си, либо для объектно-ориентированных языков C++, Java или C#, суть АОП-преобразований программ аналогична; концепции и механизмы АОП ортогональны используемым в языках парадигмам. Поэтому, на наш взгляд, в равной степени имеет смысл говорить о применении АОП к языкам процедурного, объектно-ориентированного или функционального программирования, хотя, разумеется, данный вопрос нуждается в тщательном исследовании и адаптации методов АОП для не объектно-ориентированных языков, поскольку на данный момент практически все известные инструменты АОП привязаны к системам объектно-ориентированного программирования.

С данной точки зрения, весьма важна также разработка методов формальной спецификации аспектов и их формальной верификации [1], которая в настоящий момент далека от своего решения.

Следует также отметить концептуальную связь АОП и инженерии знаний. Спецификацию аспекта можно рассматривать как представление знаний о методе решения задачи (concern) и о методе преобразования целевой программы с целью расширения ее функциональности решением рассматриваемой задачи, описанным в виде аспекта. Даже сама форма определения аспекта в любой системе поддержки АОП — совокупность правил вида Условие - Действие, — напоминает продукционную систему, где набор продукций (знаний) содержит как знания о требуемых преобразованиях целевой программы (Условие), так и знания о способе решения задачи аспектом (Действие). С данной точки зрения, представляет несомненный интерес исследование и представление аспектно-ориентированных знаний, которое только начинается. В частности, в нашей группе ведутся исследования по интеграции системы Aspect.NET c другой нашей системой — Knowledge.NET [30], инструментарием представления знаний для платформы.NET, содержащим средства представления и использования онтологий, фреймов и наборов правил.

2.2. Модели использования аспектов (join point models) С точки зрения семантики и реализации, существующие инструменты АОП [1] различаются своими моделями внедрения (join point models) — способами реализации аспектов и их внедрения. Основное различие имеет место между статическим и динамическим внедрением.

Инструменты АОП со статическим внедрением осуществляют преобразования целевой программы либо на уровне исходного кода, либо на уровне промежуточного кода (например, байт-кода Java, универсального промежуточного кода CIL платформы.NET или какоголибо собственного внутреннего представления, используемого только данным инструментом АОП), — либо, наконец, на уровне платформно-зависимого объектного кода (native code). Используется также подход, основанный на внедрении аспекта на этапе just-in-time компиляции — динамической компиляции метода из промежуточного кода в платформно-независимый объектный код при первом его вызове.

В каждой из этих моделей внедрения, в том или ином смысле, выполняется вставка кода аспекта в целевую программу. Преимущество — более высокая эффективность результирующего кода, недостаток — увеличение его объема, что не всегда приемлемо, например, для мобильных устройств с ограниченными ресурсами.

При динамическом внедрении инструмент АОП ведет себя подобно отладчику, в котором заданы контрольные точки. Для активизации аспекта, перед исполнением каждого оператора целевой программы, инструмент АОП проверяет выполнимость каждого из условий, заданных в аспекте, и при истинности какого-либо из условий выполняет соответствующее ему действие аспекта. Очевидно, что подобный подход удобен прежде всего для отладки программы, но совершенно неприемлем при ее эксплуатации, с точки зрения эффективности.

На наш взгляд, идеальный инструмент АОП должен обеспечивать гибкое сочетание статической и динамической моделей. С этой точки зрения, наиболее развитой является система AspectJ.

Вопросы к главе 1. Что такое АОП и АОРП?

2. В чем основная проблема сложности программной системы как совокупности рассредоточенных реализаций сквозных фукнкциональностей?

3. Какие методы решения данной проблемы предлагает АОП?

4. Из каких правил состоит определение аспекта, какова их структура, в чем их смысл и как они применяются к целевой программе?

5. Каковы другие основные задачи АОП, кроме раздельного описания аспектов и поддержки инструментов их внедрения?

6. Что такое аспектизация?

7. Что такое метаязык АОП и как он используется в определении аспекта?

8. В чем идея метода реализации АОП как расширения существующего языка программирования и какая широко известная система АОП реализована подобным образом?

9. Какой метод отображения конструкций метаязыка АОП в базовый язык реализации аспектов используется в системе Aspect.NET?

10. Какие концептуальные проблемы возникают при реализации АОП методом расширения базового языка программирования?

11. Сформулируйте общую точку зрения на АОП как механизм трансформаций программ, общие принципы которого не зависят от используемой парадигмы реализации программ (ООП, процедурное программирование и др.).

12. Какова концептуальная связь и в чем сходство АОП и инженерии 13. Что такое модель внедрения аспектов (join points model) и какие основные из таких моделей Вы знаете?

14. В чем суть, достоинства и недостатки статического и динамического внедрения аспектов?

Упражнения к главе 1. Разработайте в системе AspectJ (см. упражнения к главе 1) простейший аспект, вставляющий перед вызовом каждого метода в целевую программу вывод строки «Hello!», и примените его к целевому Javaприложению.

2. Проанализируйте метод обработки системой AspectJ целевого приложения и аспекта: исходный код (.aj) - байт-код (.class) - байт-код программы с внедренным аспектом - исполнение программы с внедренным аспектом.

3. Исследуйте другие возможности AspectJ: визуализацию аспектов, отладку аспектов и др.

4. Сформулируйте примеры известных Вам классов проблем и разновидностей функциональностей в программах, которые по своей сути являются сквозной функциональностью (например, проверки безопасности).

5. Спроектируйте информационную систему, хранящую анкетные данные студентов, по принципам АОП: какие модули необходимо включить в ядро системы, какие сквозные функциональности необходимо будет реализовать для этой системы?

6. Как Вы считаете, для чего лучше подходит АОП — для начального проектирования и разработки большой программной системы или для модернизации и сопровождения системы с уже существующим кодом реализации? Мотивируйте свое мнение конкретными аргументами.

ОБЗОР ИНСТРУМЕНТОВ АОП

Система AspectJ [10, 31], как уже отмечалось, — самый популярный и широко используемый инструмент АОП, фактически являющийся де-факто стандартом АОП — как набор базовых терминов АОП, так и набор функциональностей АОП. Первая версия AspectJ была разработана в 1995 году основателем АОП Грегором Кичалесом (Gregor Kiczales) и его группой в фирме Xerox PARC. Это произошло в тот же самый год, когда была выпущена первая версия Java (1.0). В настоящий момент системе AspectJ 16 лет — она достигла «юношеского возраста», как и Java-технология. На данный момент уже накоплен большой опыт обучения системе AspectJ и ее использования во всем мире. Наша система Aspect.NET намного «моложе»: ее принципы разработаны в 2003 — 2004 гг., а первый действующий прототип появился в 2005.

AspectJ — это АОП-расширение языка Java, или «аспектноориентированная Java». Текущая версия AspectJ доступна как один из проектов с открытым исходным кодом, входящих в Eclipse foundation.

AspectJ доступен как в виде отдельного продукта, так и в форме, интегрированной в среды Eclipse и NetBeans — наиболее популярные интегрированные Java IDE. На наш взгляд, наиболее удобно использовать AspectJ в форме, интегрированной в среду Eclipse (AspectJ Development Tools — AJDT [32]), благодаря удобным особенностям среды Eclipse Java IDE — относительно быстрому развертыванию и удобному пользовательскому интерфейсу. После инсталляции среды Eclipse, для того, чтобы инсталлировать ее расширение (plug-in), поддерживающее AspectJ, достаточно скачать архив AJDT, распаковать его и скопировать его содержимое в поддиректории features и plugins дерева директорий, созданного в результате инсталляции среды Eclipse.

Основные компоненты архитектуры системы AspectJ:

ajc — компилятор AspectJ. Он компилирует исходный код на языке AspectJ (языке Java, расширенном средствами АОП) в Javaбайткод, «понятный» обычной виртуальной машине Java(JVM, запускаемой командой java). Компилятор ajc доступен как в командном режиме, с большим набором опций, так и через интегрированную среду ajdoc — утилита, аналогичная утилите javadoc из JDK, которая генерирует гипертекстовую HMTL-документацию в стиле javadoc по исходному коду аспектно-ориентированной программы, написанной на языке AspectJ. Документация содержит описание структуры сквозных функциональностей, использованных в программе ajbrowser — браузер AspectJ, графический пользовательский интерфейс для визуализации аспектов, их взаимосвязей и структуры сквозных функциональностей в программе. Браузер AspectJ позволяет вызвать компилятор ajc для компиляции программ на AspectJ. Однако (в отличие от Aspect.NET) в браузере AspectJ отсутствует функциональность для выбора или отмены выбора точек присоединения аспектов AspectJ ant tasks — инструмент поддержки процесса сборки программ для популярного инструмента сборки программ на Java — Apache ant [33], аналога утилиты make AspectJ load-time weaver — «внедряющий загрузчик классов», утилита, выполняющая «отложенное» внедрение аспектов при загрузке в JVM соответствующего класса. Возможна разработка и добавление в систему внедряющих агентов времени загрузки (load-time weaving agents), решающих ту же задачу. AspectJ также поддерживает внедрение во время компиляции (выполняемое после того, как компилятор ajc транслирует единицу компиляции AspectJ) и внедрение после компиляции (при котором в качестве входной информации для внедрения аспектов используются готовый бинарный класс-файл или jarархив).

Язык AspectJ включает разнообразные возможности АОП и до сих пор используется в качестве критерия полноты реализованных возможностей АОП для многих инструментов АОП, разработанных позже него (включая и нашу систему Aspect.NET). Основные возможности AspectJ:

определения аспектов, именованные объявления разрезов (pointcuts) и межтиповые объявления (inter-type declarations). Определения аспектов содержат объявления советов (advice declarations), которые, в свою очередь, могут использовать конструкции вида thisJoinPoint для обработки информации о точках присоединения в целевых приложениях.

Заметим, что в системе Aspect.NET вместо, на наш взгляд, неудачного термина совет используется термин действие (аспекта).

Определения аспектов в AspectJ являются новой разновидностью модулей, в которых инкапсулирована некоторая сквозная функциональность, которая может быть использована путем внедрения (weaving) в целевую программу. Например: протоколирование (logging); проверки безопасности (security checks). Пример определения аспекта на языке AspectJ:

aspect Logging { //Aspect that Introduces logging behavior pointcut AnyCall (): // Named pointcut call (void MyClass.*(..));

System.out.println Данный аспект вводит функциональность для протоколирования в класс MyClass. Перед каждым вызовом каждого метода M он исполняет совет, который выводит сообщение вида: Hello M, — а после каждого вызова M — совет, который выводит аналогичное завершающее сообщение: Bye M. Для демонстрационных целей в аспект включено определение именованного разреза AnyCall, хотя в столь простом аспекте можно было бы ограничиться использованием анонимного разреза:

before(): call (void MyClass.*(..)){... } В реализациях советов использован объект thisJoinPoint, который связывает совет с точкой присоединения в целевой программе и предоставляет разнообразные возможности для обработки контекста точки присоединения. В примере использована лишь простейшая из них — неявный вызов метода thisJoinPoint.toString(), который возвращает фактическое имя целевого метода, найденного с помощью разреза. Разрезы могут быть также параметризованными, приватными и абстрактными.

Аспекты в языке AspectJ могут наследоваться от других аспектов или классов. Это вполне «в духе Java», хотя можно поспорить о том, безопасна ли эта возможность, модульна ли она или нет, может ли она вызвать «концептуальную путаницу». Предпочитаем здесь не «судить»

решение, принятое пионерами АОП.

Аспекты могут также вводить в другие классы новые межтиповые объявления (inter-type declarations):

int MyClass.VisibleFromMyAspectOnly;...

В данном примере аспект MyAspect добавляет новое поле с именем VisibleFromMyAspectOnly в класс MyClass. Это поле, в соответствии с его именем, видимо только из данного аспекта, хотя фактически становится частью класса MyClass. В языке Java добавление подобной функциональности, в самом деле, полезно. Однако, что касается.NET, подобная возможность для пошаговой разработки классов уже реализована в.NET 2.0 под названием частичные классы (partial classes):

если в каком-либо классе отсутствует некоторое необходимо поле, оно может быть добавлено в определение данного класса «в пошаговом стиле» путем его определения в отдельном текстовом файле (единице компиляции), так что для этого не требуется никаких аспектов. Кроме того, такая дисциплина видимости в AspectJ может быть нарушена путем рефлексии: хотя аспект «думает», что он — единственный владелец данного поля, класс может использовать рефлексию для доступа в этому полю, наряду с другими полями. Тем не менее, возможность межтиповых определений в AspectJ, безусловно, полезна.

Аспекты в AspectJ могут быть также определены как привилегированные (privileged). Такие аспекты имеют доступ к приватным полям целевого класса. Это — правильное решение, так как сквозная функциональность, добавляемая или расширяемая аспектом, может включать приватные данные класса. Например, приватные поля могут инкапсулировать некоторый общий ресурс, совместно используемый параллельными потоками, а аспект может быть разработан с целью добавления МП-безопасности в целевой класс.

Советы в AspectJ, определенные в аспектах, которые внедряются в целевые программы, могут быть применены перед (before), после (after) или в окрестности (around) точки присоединения (последний вариант фактически означает вместо — instead). В советах типа after может быть уточнена фактическая точка присоединения. Например, код:

after()returning (int result):

call (int MyClass.M ()) { … } означает, что совет активируется после каждого возврата из вызова метода M в классе MyClass, а результат вызова автоматически присваивается аргументу совета result и может быть проанализирован в теле совета. Аналогичным образом, возможно также уточнение точки активации совета при генерации исключения во время некоторого вызова, с последующей обработкой исключения.

В свою очередь, разрезы в AspectJ могут быть разнообразных видов и могут классифицировать различные виды точек присоединения в Java-программах достаточно тонкими способами: call — вызов некоторого метода; execution — исполнение тела метода initialization — инициализация объекта; staticinitialization — инициализация статических полей класса; set — присваивание полю; get — извлечение значения поля; handler — вызов обработчика исключения некоторого класса или его подкласса, и т. д. Если иметь в виду, что все эти варианты уточнений могут использоваться в любой комбинации с советами типа after, before или around, можно оценить по достоинству разнообразие возможностей отслеживания и обработки различных моментов исполнения Java-программы с помощью механизма советов в AspectJ.

Начиная с версии AspectJ 1.5, благодаря слиянию AspectJ с другим проектом по АОП для платформы Java — AspectWerkz [35], в AspectJ доступна альтернативная форма определения аспектов и их частей с помощью аннотаций, реализованных в Java 1.5. Система AspectWerkz сама по себе не является расширением языка Java средствами АОП. Это инструмент, поддерживающий определения аспектов с помощью аннотаций. В синтаксисе AspectWerkz, аннотация вида:

имеет семантику, сходную с обычным определением аспекта Logging на языке AspectJ, рассмотренным выше.

В данном разделе дан обзор лишь наиболее основных возможностей AspectJ. В работе [31] и документации по AJDT [32] они описаны более подробно.

Система AspectJ поддерживается некоторыми крупными компаниями — разработчиками программного обеспечения, которые поддерживают Java-технологию — IBM, Oracle и др. Она оказала огромное влияние на многих Java-программистов и исследователей в области АОП, включая специалистов моей группы и меня лично. На каждой крупной конференции по АОП и технологиям программирования в программу включается обучающий курс по AspectJ.

Считаю, что система AspectJ имеет большое будущее. Эта система наверняка будет использоваться все большим и большим числом разработчиков программного обеспечения на Java.

Однако, по-моему, возможности AspectJ гораздо более сложны для изучения и использования, тем сам базовый язык Java. Особую сложность системе AspectJ придают: тонкая и изощренная классификация различных видов точек присоединения, — например, вызов метода (call) или исполнение метода (execution); разнообразные языковые возможности, не «ортогональные» друг другу; смешение базовых концепций и конструкций Java и АОП. Многие опытные разработчики Java-программ, включая меня лично, высоко ценят мощность и историческую роль AspectJ, испытывают глубокое уважение к его авторам и осознают, что AspectJ может быть применен (и фактически уже применяется) как в промышленности, так и в исследованиях. Поистине бесценное значение AspectJ в том, что он воплощает в себе первый практически ориентированный и успешно применяемый подход к АОП. Но усложненная «кухня» из множества способов определения и внедрения аспектов в AspectJ может быть воспринята как слишком сложная большинством практиков разработки программного обеспечения. На мой взгляд, пользователей AspectJ можно разделить на две большие группы: первая — опытные Java-программисты, решающие сложные проблемы проектирования, реализации и сопровождения программ и уверенные в том, что АОП и AspectJ помогут им решить эти проблемы; вторая — молодые энтузиасты, студенты и аспиранты, с удовольствием занимающиеся исследованиями и экспериментами и очень заинтересованные в новой перспективной парадигме АОП.

3.2. Другие подходы к АОП и к проблеме разделения Разделение функциональностей (separation of concerns) [35] — одна из базовых концепций программирования, впервые сформулированная Дейкстрой (1974). С общей точки зрения, все подходы к программированию и парадигмы разработки программ — модульное программирование, объектно-ориентированное программирование (ООП), абстрактные типы данных, аспектно-ориентированное программирование — могут рассматриваться как различные методы разделения функциональностей в программах. Например, ООП — это метод разделения функциональностей в виде иерархий классов; модульное программирование — в виде библиотек модулей; АОП — это метод разделения сквозных функциональностей в виде аспектов.

Кроме АОП, существует целый ряд сходных методов, использующих несколько другую терминологию, но также предназначенных для разделения сквозных функциональностей. По-видимому, наиболее общий из таких подходов был предложен исследовательской группой фирмы IBM [36] и основан на концепциях гиперпространства (hyperspace) и многомерного разделения функциональностей (multidimensional separation of concerns). Данный подход явился основой для второй из наиболее известных в мире (после AspectJ) систем АОП — HyperJ [37], ныне доступной через сайт проектов IBM alphaWorks.

HyperJ — АОП-расширение Java, как и AspectJ, однако система HyperJ гораздо более сложна в использовании. По моему личному опыту, весьма сложной (даже, можно сказать, чересчур усложненной) задачей является разработка, модификация и понимание конфигурационных файлов в системе HyperJ. Видимо, именно подобные сложности стали причиной того, что проект HyperJ был прекращен. Однако данный подход сам по себе интересен для изучения и анализа.

Авторы определяют свою основную концепцию многомерного разделения функциональностей как «гибкое и пошаговое разделение, модуляризация и интеграция программных артефактов на основе любого числа функциональностей» [36]. В качестве основных целей своего подхода они формулируют следующие:

Инкапсуляцию всех видов функциональностей в программной системе одновременно.

Пересечение и взаимодействие функциональностей.

Повторную модуляризацию (remodularization) по требованию для инкапсуляции новых функциональностей в любой момент времени.

Основная концепция и конструкция для достижения многомерного разделения функциональностей — это гиперпространство (hyperspace) — пространство функциональностей, состоящее из гипермодулей (hypermodules) — модулей, реализующих конкретные функциональности. Основная идея, связанная с функциональностями, состоит в том, что они группируются в различные измерения (dimensions). Каждое измерение — это набор функциональностей, которые не имеют ничего объего друг с другом, т. е. не пересекаются.

Модуль (unit), точка в гиперпространстве (т. е. в модели архитектуры программной системы в целом), проектируется в точности на одну функциональность в каждой размерности. Гипермодули, в свою очередь, являются базовыми строительными блоками программной системы. Каждый гипермодуль состоит из гипервырезок (hyperslices) — совокупностей модулей, специфицируемых в терминах функциональностей в гиперпространстве, а правило композиции (composition rule) специфицирует, какм образом следует интегрировать гипервырезки.

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

Даже краткое описание данного подхода показывает, что он базируется на сложных многомерных геометрических структурах. Более простые — одномерные — геометрические аналоги могут быть использованы при рассмотрении одной из базовых концепций программирования — уровней абстракции (по Дейкстре). Каждый уровень абстракции n — это горизонтальный слой из определений модулей данного уровня, в реализации которых могут быть использованы только модули уровня n-1. Двумерная геометрическая модель получается, если к уровням абстракции добавить вертикальные слои (по Фуксману). В каждом из этих подходов каждый модуль получает свои «координаты» — одну или две. С данной точки зрения, подход IBM к многомерному моделированию функциональностей можно рассматривать как обобщение подходов Дейкстры и Фуксмана. Подобная модель, безусловно, интересна с теоретической точки зрения, однако она до сих пор не подтвердила свою практическую применимость, в отличие от подхода AspectJ. Усложненные геометрические аналоги близки к стилю мышления математиков в процессе их теоретических исследований, однако, к сожалению, геометрические концепции не столь близки большинству других людей, включая программистов. По нашему мнению, геометрические аналоги не вполне подходят для описания программных архитектур, так как возникает проблема переиспользования модулей, при котором тот же самый модуль может получить другие горизонтальную и вертикальную (или многомерные) координаты. По мнению автора, графы, в частности, деревья, являются гораздо более подходящим формализмом для этой цели.

Многомерное разделение функциональностей базируется на еще одном, более раннем подходе к композиции программ — субьектноориентированном программировании (subject-oriented programming — SOP) [39]. Субъект (subject) в данном подходе — это семантически взаимосвязанная совокупность классов и их фрагментов в объектноориентированной системе, реализующих некоторую сквозную функциональность. Объектно-ориентированная система строится из несольких субъектов, в соответствии с правилами композиции, специфицирующими способы интеграции субъектов. Такой подход предназначен для разработки систем как наборов функциональностей, причем код каждой из них хранится отдельно. Поддержка SOP для C++ была реализована в середине 1990-х гг. как расширение известной интегрированной среды IBM VisualAge.

Адаптивное программирование (adaptive programming) [39] — еще один широко известный подход к разделению функциональностей, предложенный Либергерром (Lieberherr) и реализованный его группой в системе DemeterJ, поддерживающей адаптивное программирование для Java. Адаптивное программирование — это метод проектирования и разработки объектно-ориентированной программной системы с изменяющимися иерархией классов и взаимосвязями методов. Основная идея адаптивного программирования в следующем. Метод не должен быть жестко привязан (hardwired) к деталям иерархии классов, иначе при любом изменении проекта или реализации системы потребуются значительные модификации кода. Каждый класс должен быть реализован с использованием минимальной информации об иерархии классов. Общие стратегии обхода иерархии классов должны быть специфицированы на специальном высокоуровневом языке под названием DEMETER, в соответствии с «законом Деметры», гласящим, что каждый должен взаимодействовать только со своими непосредственными друзьями (весьма полезный принцип в современных условиях, не правда ли?). Например [39], если программная система предназначена для автоматизации иерархии организационных структур в области высшего образования (министерство образования, университет, факультет, отделение, преподаватель), она может содержать метод для ответа на вопрос вида: «Сколько всего преподавателей есть в наших университетах?» Вместо очевидной реализации данного запроса, с явным посещением всех уровней иерархии, данную операцию следует реализовать в системе DEMETER как состоящую из двух частей: оператор обхода (traversal clause) — обойти всю иерархию, от министра образования до преподавателя) и обертка преподавателя (teacher wrapper) — при достижении узла, который представляет преподавателя, увеличить число преподавателей на единицу. Так что оператор обхода инкапсулирует детали иерархии классов, а обертка преподавателя — «бизнес-логику» (подсчет числа преподавателей). По нашему мнению, эти идеи очень близки более ранним принципам абстрактных типов данных (

Abstract

data types), предложенных Лисков [20], относительно инкапсуляции деталей конкретного представления в итераторах (iterators) — высокоуровневых операциях поэлементного обхода сложных структур данных. Программа на языке DEMETER затем должна быть оттранслирована в язык Java или C++. Благодаря предложенным принципам, объектно-ориентированные программы становятся более адаптируемыми к изменениям и эволюции.

Композиционные фильтры (composition filters) [41] — это подход к конструированию реализаций множественных сквозных функциональностей, предложенный группой из университета Твенте, Голландия. Модель композиционных фильтров предназначена для объектнобазированных систем (систем ООП без наследования классов), функциональность которых основана на передаче сообщений между объектами. Интерфейсная часть — видимое другим поведение объекта — определяется как набор композиционных фильтров — входного и выходного наборов фильтров. Интерфейсная часть имеет модульную структуру и не зависит от языка реализации. Она пишется на простом декларативном языке спецификаций (т. е. в стиле «что», а не «как»).

Реализационная часть, написанная на каком-либо конкретном языке реализации, например, на Java, определяет два вида методов — регулярные методы и условия (последний термин означает запросы состояния объекта, не изменяющие этого состояния). Для спецификации сквозной функциональности используется супернакладывающее предложение (superimposition clause). Данная модель была реализована для трех языков Smalltalk, C++ и Java.

Интересный с практической точки зрения подход, получивший название графы функциональностей (concern graphs) [42], предложен и реализован в системе FEAT Робилларом и Мэрфи (Robillard and Murphy). В нем модели программ рассматриваются как помеченные ориентированные графы — форма, которая, на наш взгляд, гораздо более адекватна, чем многомерные геометрические структуры, для описания взаимосвязей в программной системе. Система FEAT, как и AspectJ, реализована как расширение (plug-in) к популярной интегрированной среде Eclipse. Система FEAT позволяет визуализировать реализации функциональностей и их компоненты явным образом — например, для каждого метода увидеть, из каких других методов он вызывается и какими другими методами он перегружен. Система позволяет пользователю построить полный граф функциональностей (concern graph) программной системы в терминах ее типов, методов и полей и их взаимосвязей. Более того, она позволяет обнаруживать несколько видов несогласованностей в исходных кодах. Все это весьма полезно для лучшего понимания пользователями структуры и функциональностей программной системы и для их модификации, требуемых в процессе разработки. Графы функциональностей в системе FEAT помогают пользователям решать до сих пор одну из наиболее сложных задач разработки и сопровождения программ — понимания и модификации существующего программного кода.

В заключении данного краткого обзора (более полный приведен в работе [1]) кратко перечислим другие близкие интересные подходы к разработке и модификации программ:

интенциональное программирование (intentional programming) [43] — подход, основанный на идее отражения в исходном коде программной системы исходных намерений (intentions) разработчиков системы, выраженных на соответствующем уровне абстракции генерационное программирование (generative programming) [44] — подход, основанный, по словам его авторов, «на моделировании и реализации семейств систем таким образом, что заданная система может быть автоматически сгенерирована из спецификации, написанной на одном или несскольких текстовых или или графических языков, ориентированных на предметную область».

Возвращаясь к АОП и его инструментам, в заключение данной главы отметим, что в настоящее время инструменты АОП реализованы для многих традиционных и современных языков и платформ: Java, C, C++, JavaScript, C#.NET, VB.NET, Cobol, Perl, PHP, Lua, Python, Ruby, XML и т. д. Web-страница АОП в Wikipedia [45] и сайт по АОП [22] содержат описание сотен разнообразных инструментов АОП.

Вопросы к главе Каково назначение системы AspectJ?

Каковы основные компоненты архитектуры AspectJ?

Что такое определение аспекта в AspectJ?

Что такое объявление разреза в AspectJ?

Что такое межтиповые объявления в AspectJ?

Какие модели внедрения аспектов используются в AspectJ?

Что такое привилегированные аспекты в AspectJ?

Какая альтернативная форма определения аспектов с помощью аннотаций введена в AspectJ при его интеграции с системой AspectWerkz?

В чем, по-Вашему, сложности использования AspectJ?

Что такое уровень абстракции?

Что такое разделение функциональностей?

Каковы основные принципы системы HyperJ?

Что такое субьектно-ориентированное программирование?

Что такое адаптивное программирование?

Что такое генерационное программирование?

Что такое интенциональное программирование?

Что такое граф функциональностей (в системе FEAT)?

Упражнения к главе 1. Скачайте и инсталлируйте систему AspectJ в составе интегрированной среды Eclipse 2. Разработайте в системе AspectJ аспект протоколирования, который в начале вызова каждого метода M выводит сообщение Hello M, а в конце каждого вызова — сообщение Bye M. Затем добавьте к этому аспекту вывод значений аргументов метода и его результата.

ПРИНЦИПЫ И АРХИТЕКТУРА СИСТЕМЫ

Знакомство автора с АОП началось в 2001 г. с номера журнала Communications of the ACM [46], посвященного АОП. Содержание его статей позволило мне неожиданно для себя увериться в том, что фактически я уже являюсь сторонником АОП, так как развивал и использовал аналогичные принципы разработки программ в течение всей своей профессиональной деятельности.

В частности, цели ТИП-технологии [47], разработанной автором в 1980-х гг. и использованной нашим коллективом в течение ряда лет для разработки компиляторов и экспертных систем, состояли, выражаясь современным языком, в поддержке шаблонов проектирования и реализации операций над сложными структурами данных в виде предопределенного набора уровней абстракции (уровень представления, уровень определения, концептуальный уровень) и вертикальных срезов (интерфейс генерации/удаления, интерфейс доступа, интерфейс модификации, интерфейс вывода), — реализуемых в виде информационно прочного [18] многовходового модуля — технологического инструментального пакета (ТИП). Использование (внедрение) ТИП путем вызова его абстрактных операций, в отличие от внедрения аспекта в АОП, не было автоматизировано, не опиралось на какие-либо инструменты, отсутствовал метаязык определения разрезов и правил внедрения ТИП, однако элементами технологической дисциплины ТИПтехнологии были семантические рекомендации по использованию операций ТИП [47] и мнемонические обозначения точек использования (присоединения) ТИП в виде комментариев, например:

%List% p := Cons (1, Nil);

что облегчало локализацию с помощью редактора или текстовых фильтров в исходном коде программы всех фрагментов (действий) ТИП. Таким образом, ТИП-технология [47], как и технология вертикального слоения [21], была шагом вперед на пути к АОП.

Как известно, значительную трудность для большинства программистов при сопровождении больших программных систем представляют выделение и модификация сквозной функциональности. Для исправления ошибки или недоработки в программе (например, отсутствие синхронизирующих скобок при модификации общего ресурса), программисту приходится, используя средства универсальной интегрированной среды, во-первых, найти в программе все вызовы операции изменения ресурса — например, SetResource (NewValue), — вовторых, заключить все эти вызовы в синхронизирующие скобки — например, вставить вызов операции Wait (Semaphore) перед каждым вызовом SetResource, а вызов операции Signal (Semaphore) — после каждого вызова SetResource. Указанные групповые модификации кода выполняются средствами текстового редактора интегрированной среды. При этом, в лучшем случае, в среде автоматизирован поиск всех вызовов заданного метода (например, в виде одной из опций функции refactoring), — либо и такая возможность отсутствует, и для поиска приходится использовать сторонние утилиты типа grep. Для надежности и безопасности вставки кода синхронизирующих скобок универсальная среда разработки не обеспечивает никакой поддержки, кроме базовых возможностей редактора (Copy / Paste). Таким образом, ситуация, когда программист вставил в код только вызов Wait, но забыл вставить вызов Signal, не контролируется технологией разработки.

Рассмотрим, как описанная выше задача решается в АОП, в системе Aspect.NET — с помощью определения и внедрения простого аспекта:

%aspect SemaphoreBrackets public class SemaphoreBrackets { %before %call *.SetResource public static void WaitAction () %after %call *.SetResource public static void SignalAction () } // SemaphoreBrackets Аспект SemaphoreBrackets состоит из двух действий — WaitAction и SignalAction, статических методов, вызовы которых, согласно правилам внедрения аспекта, вставляются в код целевой программы соответственно, перед каждым вызовом и после каждого вызова метода SetResource.

Строки исходного кода аспекта, начинающиеся знаком процента (%), представляют собой аспектно-ориентированные аннотации, или, иначе говоря, конструкции метаязыка АОП — Aspect.NET.ML, являющегося частью нашей системы. Весь остальной код — это обычный, синтаксически и семантически правильный код определения класса на C#. Конструкции метаязыка Aspect.NET.ML конвертируются в определения специализированных атрибутов (custom attributes).NET на языке C#. Этап конвертирования является первым шагом процесса сборки проекта в Visual Studio. Например, код на метаязыке Aspect.NET.ML:

%before %call *.SetResource %action будет конвертирован в следующий код на C#:

[AspectAction("%before %call *.SetResource")] — код, аннотирующий метод SetResource экземпляром специализированного атрибута АОП AspectAction (действие аспекта).

В действиях аспекта могут быть использованы конструкции для анализа контекста точки присоединения, что совершенно необходимо для реальных применений АОП. Например, вывод на консоль имени метода в целевой программе, перед вызовом которого вставлен вызов действия аспекта, выполняется следующим образом:

System.Console.WriteLine ("Target method name=" +% TargetMemberInfo.Name);

Аналогичным образом, возможна обработка («захват») аргументов и результатов целевого метода; объекта, к которому применяется метод в целевой программе; имени файла и номера строки точки присоединения аспекта в целевой программе и т. д.

Пользователь Aspect.NET имеет возможность для разработки определения нового аспекта использовать любой из двух видов проекта Visual Studio.NET, которыми Aspect.NET расширяет стандартный набор типов проектов Visual Studio, — Aspect.NET.ML module (код на метаязыке АОП) и Aspect.NET modulе — код на C#, в котором специализированные атрибуты АОП можно задавать непосредственно и, таким образом, разрабатывать аспекты «в атрибутах», не используя метаязыка АОП вообще. Однако, в отличие от конструкций АОП в AspectJ, конструкции метаязыка Aspect.NET.ML очень просты и могут быть быстро освоены с помощью примеров и шаблонов кода, введенных в Visual Studio для проектов типа Aspect.NET.ML module.

Полученный в результате конвертирования исходный код на C# (VB) компилируется в универсальный промежуточный код CIL платформы.NET стандартными средствами Visual Studio. Бинарный код сборки (файл переносимого кода, portable executable, платформы.NET) несет в себе информацию не только о коде класса, но и о принадлежности его фрагментов (действий, реализуемых методами) аспекту SemaphoreBrackets. Это не препятствует работе стандартных утилит.NET (например, отладчика), но позволяет системе Aspect.NET, используя атрибуты, «понимать» аспекты, представленные в виде двоичных кодов сборок. Использование атрибутов АОП более надежно, чем распространенная во многих других инструментах АОП спецификация аспектов в виде отдельных XML-файлов.

Вставка кода действий аспекта в Aspect.NET выполняется автоматически подсистемой внедрения аспектов (weaver). При этом гарантируется надежность и полнота выполнения данной групповой модификации: Aspect.NET не может «случайно забыть» выполнить вставку какого-либо действия аспекта. Подсистема внедрения аспектов вызывается через интегрированную среду — Aspect.NET Framework, являющуюся частью (add-in) универсальной интегрированной среды Visual Studio.NET. Для обработки сборок.NET подсистема внедрения аспектов использует инструментарий Microsoft Phoenix [48], предназначенный для создания платформно-зависимых частей (back-ends) компиляторов и разработки всевозможных утилит обработки программ. Пользователем Phoenix, в рамках программы Phoenix Academic Program [29], наша группа, по приглашению Microsoft Research, является с 2003 года.

Среда Aspect.NET Framework обеспечивает открытие аспектов, представленных двоичными сборками, запоминание открытых аспектов для последующих открытий той же целевой программы в Visual Studio, визуализацию аспектов, вызов подсистемы внедрения, визуализацию точек присоединения аспектов в целевой программе, а также пробный запуск одним нажатием кнопки полученного в результате внедрения аспектов двоичного кода сборки.NET.

Aspect.NET, единственный из известных на данный момент инструментов АОП, обеспечивает режим внедрения аспектов, управляемого пользователем (user-controlled weaving). Перед фактическим внедрением аспектов пользователь имеет возможность просмотреть все найденные Aspect.NET потенциальные точки присоединения аспекта в исходном коде целевой программы, проанализировать возможный эффект внедрения действий аспекта в каждую из этих точек, отменить (deselect) те из них, внедрение в которые нежелательно, и лишь затем выполнить внедрение аспекта. Таким образом, наша система позволяет избежать самой серьезной опасности, которую таит в себе АОП как мощный механизм групповых преобразований кода, — «слепого», бесконтрольного изменения поведения программы, последствия которого нетрудно предвидеть.

Вопреки распространенной точке зрения о неэффективности применения АОП, в отличие от «ручной» вставки аналогичных фрагментов кода, Aspect.NET не ухудшает эффективность результирующей программы [1]. Вставки или замены выполняются на уровне бинарного кода сборки (assembly). При этом, как правило, кроме самих вызовов действий аспекта, в код целевой программы не вставляется никакого дополнительного «инструментовочного» кода, т. е. результат внедрения аспекта в сборку ничем не отличается от результата ее аналогичной ручной модификации. Полученная сборка может использоваться всеми универсальными инструментами.NET — общей средой поддержки выполнения (CLR), отладчиком, профилировщиком (profiler) и т. д.

Суммируя сказанное, отметим, что наша система Aspect.NET использует и развивает наиболее важные черты архитектуры.NET — открытость; ориентацию на многоязыковое программирование на основе единого промежуточного кода MSIL; применение пользовательских атрибутов (custom attributes) для аннотирования и расширения программ (в Aspect.NET, как мы уже видели, атрибуты используются для аннотирования методов информацией об аспектах, которым они принадлежат).

Аспект в системе Aspect.NET определяется как исходный код класса (в наиболее общем виде — код единицы компиляции) на языке C# или Visual Basic (в будущем — на любом другом языке, реализованном в.NET), аннотированный конструкциями нашего метаязыка АОП (называемого Aspect.NET.ML) с целью выделения частей определения аспекта.

Определение аспекта сосстоит из следующих частей:

заголовок аспекта (aspect header);

(необязательные) данные аспекта (aspect data) — как правило, приватные поля;

модули аспекта (aspect modules) — методы или функции;

правила внедрения аспекта (aspect weaving rules), которые, в свою очередь, состоят из условий внедрения (weaving conditions) и действий (actions), которые, в соответствии с заданными правилами, должны быть внедрены (woven) в целевую сборку.

В Aspect.NET 2.2 поддерживается возможность определения аспектов на языках Aspect.NET.ML и C#, либо на языках Aspect.NET.ML и Visual Basic, либо только на C# (Visual Basic) «в атрибутах», без использования метаязыка. Поддержка всех остальных основных языков, реализованных в.NET (Managed C++, F# и др.) планируется в ближайших следующих версиях.

Сразу отметим, что структура метаязыка Aspect.NET.ML и его семантика не привязаны к конкретному языку реализации, что позволит использовать одни и те же спецификации аспектов на Aspect.NET.ML в сочетании с различными языками их реализации. Подобная языковая независимость метаязыка АОП — важный принцип Aspect.NET.

Правила внедрения аспекта определяют точки присоединения (join points) в целевой программе, в которые должны быть добавлены действия аспекта. Именно действия аспекта, в конечном счете, определяют его функциональность.

Препроцессоры (конверторы) Aspect.NET преобразуют аннотации АОП в определения специализированных атрибутов АОП (AOP custom attributes), специально спроектированных для Aspect.NET, на языках C# (VB). Атрибуты АОП помечают классы и методы как части определения аспекта (см. рис. 4.1). Далее, соответствующий штатный компилятор Visual Studio.NET (для Aspect.NET 2.2 — компилятор с языка C# или VB) преобразует специализированные атрибуты АОП в метаданные (metadata) аспектной сборки (aspect assembly), которые, согласно общим принципам архитектуры.NET, хранятся в сборке вместе с ее кодом на промежуточном языке MSIL.

Точки присоединения в Aspect.NET определяются по правилам внедрения, которые либо являются частью определения аспекта, либо определены в отдельном модуле — наборе правил (rule set).

В Aspect.NET 2.2 наборы правил не реализованы; их реализация планируется в следующих версиях.

Правила внедрения содержат:

условия (conditions), определяющие точку вызова действия аспекта относительно конкретной точки присоединения в целевой программе: before — перед точкой присоединения; after — после точки присоединения; instead — вместо кода (вызова), являющегося точкой присоединения;

контекст (context) вызова действия аспекта: ключевое слово call — вызов некоторого метода в целевой программе; assign — присваивание переменной (полю) в целевой программе; use — использование переменной (поля); за ключевым словом следует шаблон (wildcard) для поиска в целевой программе контекста вызова действия аспекта.

В Aspect.NET 2.2 реализованы точки присоединения вида call (вызов). Реализация других видов точек присоединения планируется в следующих версиях. Практика показала, что именно точки присоединения типа call наиболее важны, и практически любую необходимую АОП-трансформацию программы можно выразить в терминах внедений аспектов в такие точки.

Процесс внедрения аспекта состоит из двух фаз: сканирования (scanning) — поиска потенциальных точек внедрения в целевой программе, — и собственно внедрения (weaving) вызовов действий аспекта в найденные точки присоединения.

Одним из важнейших принципов Aspect.NET, в отличие от многих других инструментов АОП, является возможность внедрения, управляемого пользователем (user-controlled weaving). По завершении фазы сканирования, Aspect.NET позволяет пользователю отметить (select) или отменить отметку (deselect) любой из найденных потенциальных точек внедрения, используя Aspect.NET Framework GUI. Это позволяет избежать синдрома «слепого внедрения» (blind weaving) без какого-либо контроля его результатов, что могло бы сделать результирующий код целевой программы неясным или вообще ошибочным и затруднить его отладку. Таким образом, в Aspect.NET окончательный выбор, внедрять или не внедрять аспект в ту или иную точку присоединения, остается за пользователем.

Пользователь может определять аспекты либо в форме Aspect.NET.ML, либо непосредственно в терминах специализированных атрибутов на языке C# (или VB), без использования метаязыка.

Aspect.NET Framework поддерживает два соответствующих типа проектов для определения аспектов.

Основные компоненты Aspect.NET — подсистема внедрения (weaver), конвертор метаязыка (meta-language converter) и Aspect.NET Framework — и их взаимосвязь изображены на риc. 4.2.

Очень важно, что результат работы Aspect.NET — двоичная сборка (assembly) модифицированной целевой программы — является, с точки зрения обычных пользователей и инструментов.NET, не связанных с АОП, совершенно стандартной сборкой и может обрабатываться любым штатным инструментом.NET.

Более подобное описание метаязыка определения аспектов Aspect.NET.ML и методы практического использования Aspect.NET в среде Visual Studio даны в последующих двух главах 5 и 6.

Вопросы к главе 1. Что такое ТИП-технология и каково ее назначение?

2. Сформулируйте проблемы разработки и модификации сквозной функциональности.

3. Как решаются эти проблемы с помощью АОП и Aspect.NEТ?

4. Что такое Aspect.NET.ML и как он используется в системе 5. Как используются в системе Aspect.NET специализированные атрибуты (custom arrtibutes)?

6. Что такое конвертор Aspect.NET.ML в определения атрибутов и каково его назначение?

7. Какие языки определения аспектов поддержаны в текущей версии 8. Что такое Aspect.NET Framework?

9. Из каких основных компонент состоит система Aspect.NET, каким образом они взаимодействуют между собой и с интегрированной средой Visual Studio?

Упражнения к главе 1. Скачайте Aspect.NET 2.2 и используемый в нем инструмент — Phoenix RDK March 2007. Инсталлируйте (поверх Visual Studio 2005) сначала Phoenix RDK, затем — Aspect.NET. Ссылка на Phoenix RDK дана на странице проекта Aspect.NET: http://www.aspectdotnet.org. Там же прочтите все другие требования (pre-requisites) к окружению для инсталляции и использования Aspect.NET и выполните их (проверьте, что они выполнены).

2. Пропустите все примеры целевых приложений и аспектов, поставляемых вместе с Aspect.NET 2.2. Проанализируйте результаты.

3. Пропустите все примеры аспектов, опубликованные на странице проекта Aspect.NET, из книги [1]. Проанализируйте результаты.

4. Разработайте аспект, заменяющий реализации всех методов на заглушки, единственной функцией которых является вывод имени вызываемого метода.

5. Разработайте аспект, заменяющий каждый вызов метода void M() на его «обертку», вызывающую тот же самый метод, но обрабатывающую все возможные исключения, которые могут возникнуть при вызове данного метода. В случае генерации исключения аспект должен его перехватывать и выводить в стандартный вывод сообщение с именем возникшего исключения, после чего должна продолжаться нормальная работа программы.

МЕТАЯЗЫК СПЕЦИФИКАЦИИ АСПЕКТОВ

5.1. Синтаксис и семантика Aspect.NET.ML Рассмотрим подробнее синтаксис и семантику конструкций метаязыка АОП — Aspect.NET.ML, соответствующих версии Aspect.NET 2.2. Синтаксические определения приведены в расширенной форме Бэкуса-Наура (РБНФ). Ключевые слова Aspect.NET.ML (например, %aspect) даны жирным шрифтом. Метасимволы РБНФ, например:

[]*|.

(точка обозначает конец синтаксического правила) также даны жирным шрифтом.

Каждая конструкция метаязыка — это АОП-аннотация, конвертируемая на этапе сборки аспекта в определения специалилированных атрибутов АОП на соответствующем языке реализации (C# или VB).

Структура и семантика метаязыка не зависят от языка реализации, т. е. при реализации аспекта на C# или VB метаязык используется один и тот же. В этом — один из важнейших принципов Aspect.NET, поддерживающий многоязыковое АОП (см. главу 9). Насколько нам известно, в настоящее время Aspect.NET — единственная система, поддерживающая многоязыково аспектно-ориентированное программирование.

Заметим, что в системе Aspect.NET возможно использование непосредственно АОП-атрибутов для определения аспектов, без использования метаязыка Aspect.NET.ML.

Заметим также, что метаязык Aspect.NET.ML спроектирован таким образом, что, если «забыть об АОП» — удалить или закомментировать конструкции метаязыка которые при этом должны быть в отдельных строках исходного кода, — то получившийся код будет синтаксически и семантически правильным исходным кодом на языке реализации аспекта (C# или VB). В этом — также один из основных принципов Aspect.NET и наша принципиальная позиция. Наша система не «навязывает» новые конструкции АОП; они могут рассматриваться как комментарии, и при этом пользователь может продолжать работать в интегрированной среде и использовать исходный код аспекта как обычный исходный код класса. Для сравнения, в системе AspectJ подобные преобразования программ невозможны.

Синтаксис AspectDefinition = %aspect AspectName CSharpClassDefinitionWithModulesAndActions.

AspectName = Id.

Семантика Определение аспекта начинается с его заголовка — ключевого слова %aspect, за которым следует имя аспекта. За заголовком следует тело аспекта, которое может быть любым определением класса на языке C#. Имя класса должно совпадать с именем аспекта.

Заголовок класса (class AspectName) может отсутствовать. В таком случае он автоматически генерируется конвертором Aspect.NET.ML.

Класс, реализующий определение аспекта, должен содержать определения модулей (после ключевого слова %modules) и правил внедрения (после ключевого слова %rules).

Модули аспекта (раздел modules не обязателен), как правило, должны быть приватными методами класса.

Заметим, что такой подход отличается от подхода AspectJ. Мы не вводим в Aspect.NET новую разновидность конструкции в сам язык C#, а вместо этого предоставляем простые и наглядные аннотации к коду на C#, объясняющие пользователям и самой системе Aspect.NET, что данный код определения класса должен рассматриваться как аспект. Мы считаем, что такой подход гораздо проще, не создает коллизий аспектов и классов на уровне языка реализации, а в будущих версиях Aspect.NET он позволит нам использовать аналогичные АОПаннотации для кода на других языках платформы.NET, например, на Managed C++ (в версии 2.2 уже возможно использовать второй язык реализации — VB.NET).

Синтаксис AspectWeavingRulesSection = WeavingRule +.

WeavingRule = WeavingRuleCondition WeavingRuleAction.

WeavingRuleCondition = WeavingRuleConditionClause [ '||' WeavingRuleConditionClause ] *.

WeavingRuleConditionClause = WeavingContext JoinPointKind WeavingContext = %before | %after | %instead.

JoinPointKind = MethodPattern = MethodNameFilter [ MethodArgumentTypes ] [ Restrictions ].

MethodArgumentTypes = ' (' '..' | CLRType [', ' CLRType]* ') '.

MethodNameFilter = [ public | private | *] [static] [CLRType| *] MethodNameWildCard.

Restrictions = Restriction [ '&&' Restriction ] *.

Restriction = %args '(' arg'[' IntLiteral ']' [ ', ' arg'[' IntLiteral ']' ] * ')' | %args '(..)' | %[ '!' ]within '(' TypeNameWildCard')' | %[ '!' ]withincode '(' MethodNameWildCard ')'.

WeavingRuleAction = %action PublicStaticMethodDef.

Примеры %after %call * %action public static void SayBye () { System.Console.WriteLine("Bye"); } Данное правило внедрения обеспечивает следующую функциональность: после каждого вызова каждого метода в целевой программе вставляется вызов статического метода (действия) SayBye(), который выводит сообщение «Bye» на консоль. Таким образом, применение подобного рода правил внедрения существенно упрощает реализацию протоколирования целевых программ.

%instead %call *BankAccount.withdraw(float)&&args(..) %action public static float WithdrawWrapper (float amount) (BankAccount)TargetObject;

("Withdraw operation is not allowed");

Данное правило внедрения обеспечивает следующую функциональность. В целевом приложении, как предполагается в определении аспекта, должны быть классы, имена которых оканчиваются на BankAccount. В таких классах, как предполагается, должен быть статический метод withdraw с одним аргументом типа float. В соответствии с данным правилом, все такие вызовы метода withdraw будут заменены на вызовы нового метода WithdrawWrapper (действия аспекта — «обертки» для метода withdraw), реализующего некоторые дополнительные проверки, которые необходимо выполнить перед вызовом банковской операции снятия со счета (withdraw).

Ограничение args(..) означает, что все аргументы целевого метода withdraw будут захвачены и обработаны как соответствующие аргументы действия аспекта. В соответствии с данным ограничением, действие аспекта WithdrawWrapper также имеет ровно один аргумент типа float. Функциональность args реализована аналогично возможностям системы AspectJ.

Примеры фильтрации методов Возможность фильтрации методов по их сигнатурам — весьма важный и мощный инструмент. Вот несколько примеров фильтрации методов:



Pages:   || 2 | 3 |
 
Похожие работы:

«Методическое пособие по Ведению дебатов в Британском/Всемирном парламентском формате Методическое пособие по Ведению дебатов в Британском/Всемирном парламентском формате Нил Харви-Смит Перевод А.А.Беляева Международная образовательная ассоциация дебатов (IDEA) Нью-Йорк, Лондон, Амстердам Харви-Смит Н. Методическое пособие по ведению дебатов в Британском/ Всемирном парламентском формате / Нил Харви-Смит. Издатель: Международная образовательная ассоциация дебатов /ru.idebate.org/ International...»

«В.В. Коротаев, Г.С. Мельников, С.В. Михеев ОСНОВЫ ТЕПЛОВИДЕНИЯ Санкт-Петербург 2012 МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ САНКТ-ПЕТЕРБУРГСКИЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ, МЕХАНИКИ И ОПТИКИ b В.В. Коротаев, Г.С. Мельников, С.В. Михеев, В.М. Самков, Ю.И. Солдатов ОСНОВЫ ТЕПЛОВИДЕНИЯ Учебное пособие Санкт-Петербург 2012 В. В. Коротаев, Г.С. Мельников, С. В. Михеев, В. М. Самков, Ю. И. Солдатов. Основы тепловидения – СПб: НИУ ИТМО,2012 – 122...»

«Министерство образования и науки Российской Федерации Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Оренбургский государственный университет Факультет дистанционных образовательных технологий Университетская физическая школа А.А. Чакак ФИЗИКА Выпуск 1 Кинематика механического движения Рекомендовано к изданию Ученым советом федерального государственного бюджетного образовательного учреждения высшего профессионального образования...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ НОУ ВПО ОМСКАЯ ГУМАНИТАРНАЯ АКАДЕМИЯ О.Ю. Патласов, О.В. Сергиенко АНТИКРИЗИСНОЕ УПРАВЛЕНИЕ. ФИНАНСОВОЕ МОДЕЛИРОВАНИЕ И ДИАГНОСТИКА БАНКРОТСТВА КОММЕРЧЕСКОЙ ОРГАНИЗАЦИИ Учебное пособие Допущено Советом Учебно-методического объединения по образованию в области менеджмента в качестве учебного пособия по специальности Менеджмент организации Омск Издательство НОУ ВПО ОмГА 2008 УДК 343.535; 339.5; 631. ББК 67.404; 65.290- П Рецензенты: зав....»

«МИНИСТЕРСТВО СЕЛЬСКОГО ХОЗЯЙСТВА И ПРОДОВОЛЬСТВИЯ РЕСПУБЛИКИ БЕЛАРУСЬ УЧРЕЖДЕНИЕ ОБРАЗОВАНИЯ ГРОДНЕНСКИЙ ГОСУДАРСТВЕННЫЙ АГРАРНЫЙ УНИВЕРСИТЕТ Кафедра механизации сельскохозяйственного производства МЕТОДИЧЕСКОЕ ПОСОБИЕ к выполнению лабораторных работ по разделу Сельскохозяйственные машины дисциплины Механизация технологических процессов в земледелии для студентов заочной формы обучения специальности 1-74 02 01 Агрономия Гродно 2012 УДК 631.3(072) ББК 40.72 М 54 Авторы: С.Н. Ладутько, Э.В. Заяц,...»

«ХИМИЯ МЕТОДИЧЕСКИЕ УКАЗАНИЯ, ПРОГРАММА, РЕШЕНИЕ ТИПОВЫХ ЗАДАЧ И КОНТРОЛЬНЫЕ ЗАДАНИЯ ДЛЯ СТУДЕНТОВ ЗАОЧНОГО ОТДЕЛЕНИЯ ИНЖЕНЕРНО-ТЕХНИЧЕСКИХ СПЕЦИАЛЬНОСТЕЙ Химия. Методические указания, программа, решение типовых задач и контрольные задания для студентов заочного отделения инженерно-экономических специальностей. – СПб.: Изд-во СПбГАСЭ, 2004. – 87 с. Под редакцией И.Л. Шиманович ПРОГРАММА Содержание курса и объем требований, предъявляемых студенту при сдаче экзамена, определяет программа по химии...»

«1 ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ РФ ГОУ ВПО КЕМЕРОВСКИЙ ТЕХНОЛОГИЧЕСКИЙ ИНСТИТУТ ПИЩЕВОЙ ПРОМЫШЛЕННОСТИ Кафедра АПП и АСУ ЛАБОРАТОРНЫЙ ПРАКТИКУМ Методические указания по дисциплине Автоматизация пищевых производств для студентов, обучающихся по специальности 220301 Автоматизация пищевых процессов и производств, всех форм обучения Кемерово 2008 2 Составители: А.В. Чупин, доцент, канд. техн. наук; С.Г. Пачкин, доцент, канд. техн. наук, Рассмотрено и утверждено на заседании кафедры АПП и АСУ...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ РЕСПУБЛИКИ БЕЛАРУСЬ БЕЛОРУССКИЙ НАЦИОНАЛЬНЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ И.В.Качанов, А.Д.Молокович, С.А.Шавилков ЭКОНОМИКА ВОДНОГО ТРАНСПОРТА Минск 2006 УДК 656.7 (075.8) ББК 65.37 и 7 К 142 Р е ц е н з е н т ы: Качанов, И.В. Экономика водного транспорта: учебное пособие/И.В.Качанов, А.Д.Молокович, С.А.Шавилков. – Мн.:БНТУ, 2006. – 184 с. ISBN 985-479 Рассматривается современный экономический механизм, обеспечивающий жизнедеятельность предприятий водного транспорта в...»

«САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ Факультет прикладной математики – процессов управления Л. К. БАБАДЖАНЯНЦ Ю. А. ПУПЫШЕВ Ю. Ю. ПУПЫШЕВА КЛАССИЧЕСКАЯ МЕХАНИКА Учебное пособие Издание третье, исправленное Санкт-Петербург 2013 Перейти к оглавлению на странице: 256 ПРЕДИСЛОВИЕ ПРЕДИСЛОВИЕ К ПЕРВОМУ ИЗДАНИЮ (2008 ГОД) Теоретическая часть настоящего курса содержит материал, соответствующий лекциям, которые Л.К. Бабаджанянц читает студентам факультета прикладной математики – процессов...»

«РОССИЙСКАЯ ФЕДЕРАЦИЯ ВСЕРОССИЙСКИЙ ПРОФЕССИОНАЛЬНЫЙ СОЮЗ РАБОТНИКОВ АУДИТОРСКИХ, ОЦЕНОЧНЫХ, ЭКСПЕРТНЫХ И КОНСАЛТИНГОВЫХ ОРГАНИЗАЦИЙ И СПОЛНИТЕЛЬНЫЙ К ОМИТЕТ 107078 Москва а/я 99 тел. +7(495)980-1298 info@profsro.ru РЕКОМЕНДАЦИИ №224 от 10.09.2010 В ПОМОЩЬ ПРОФСОЮЗНЫМ ОРГАНИЗАЦИЯМ ВСЕРОССИЙСКОГО ПРОФЕССИОНАЛЬНОГО СОЮЗА РАБОТНИКОВ АУДИТОРСКИХ, ОЦЕНОЧНЫХ, ЭКСПЕРТНЫХ И КОНСАЛТИНГОВЫХ ОРГАНИЗАЦИЙ. АНАЛИЗ СУДЕБНОЙ ПРАКТИКИ ПО ТРУДОВЫМ СПОРАМ НОВАЯ ПРАКТИКА ВЕРХОВНОГО СУДА РФ И КОНСТИТУЦИОННОГО СУДА...»

«Методические рекомендации по использованию набора ЦОР Химия для 11 класса Авторы: Черникова С. В., Федорова В. Н. Тема 1. Строение атома Урок 1. Атом – сложная частица Цель урока: на основе межпредметных связей с физикой рассмотреть доказательства сложности строения атома, модели строения атома, развить представления о строении атома. На данном уроке учитель актуализирует знания учащихся об атоме, для чего организует изучение и обсуждение ЦОР Развитие классической теории строения атома...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ РЕСПУБЛИКИ БЕЛАРУСЬ Брестский политехнический институт МЕТОДИЧЕСКИЕ УКАЗАНИЯ И КОНТРОЛЬНЫЕ РАБОТЫ ПО ФИЗИКЕ Брест 2000 Методические указания и контрольные работы по физике для слушателей факультета довузовской подготовки. Брест, БрПИ, 2000. Составители: Г.С.Кандилян, ст. преподаватель И.Н.Прокопеня, инженер-программист Н.И.Чопчиц, доцент Л.Н.Яромская, ассистент © Брестский политехнический институт 2000 ПРЕДИСЛОВИЕ Цель настоящего пособия - оказать помощь слушателям...»

«МИНИСТЕРСТВО ЗДРАВООХРАНЕНИЯ РЕСПУБЛИКИ БЕЛАРУСЬ Белорусская медицинская академия последипломного образования Кафедра психотерапии и медицинской психологии Байкова Ирина Анатольевна Боль. Методы терапии боли. Учебно-методическое пособие Минск, 2004 1 Б18 Автор: кандидат медицинских наук, доцент Байкова И.А. Рецензент: кандидат медицинских наук, доцент кафедры психиатрии Белорусской медицинской академии последипломного образования, Е.В. Ласый Утверждено Советом терапевтического факультета в...»

«Герасин, О. Н. Учетное обеспечение объектов интеллектуальной собственности Оглавление диссертации кандидат экономических наук Герасин, Олег Николаевич ВВЕДЕНИЕ. 1 ТЕОРЕТИЧЕСКИЕ ОСНОВЫ БУХГАЛТЕРСКОГО ОБЕСПЕЧЕНИЯ ОБЪЕКТОВ ИНТЕЛЛЕКТУАЛЬНОЙ СОБСТВЕННОСТИ. 1.1 Анализ терминологического аппарата и экономической сущности объектов интеллектуальной собственности. 1.2 Классификационные критерии объектов интеллектуальной собственности. 1.3 Экономические механизмы использования объектов интеллектуальной...»

«Министерство образования и науки РФ Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования Сибирская государственная автомобильно – дорожная академия (СибАДИ) Кафедра Строительство и эксплуатация дорог Н.П. Александрова, Т.В. Семенова Конспект лекций, методическое указание к выполнению контрольной работы по дисциплине Механизация дорожных технологий и рекомендации к прохождению учебной практики для студентов всех форм обучения направления 270800...»

«Экономические механизмы решения глобальных экологических проблем в России Материалы 9-й Международной конференции Российского общества экологической экономики Economic mechanisms of the decision of global environmental problems in Russia Proceedings of the 9th International Conference of the Russian Society for Ecological Economics Барнаул — Barnaul — 2008 Международное общество экологической экономики Российское общество экологической экономики Российская экономическая академия им. Г.В....»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ РОССИЙСКОЙ ФЕДЕРАЦИИ УХТИНСКИЙ ГОСУДАРСТВЕННЫЙ ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ И.К.Серов, Э.А.Перфильева, А.В.Тарсин, Г.П.Филиппов ФИЗИКА Часть 2 Учебное пособие 2-е издание Ухта 2002 УДК 53 (075) C32 ББК 22.3 Физика. Часть 2. Учебное пособие / И.К. Серов, Э.А.Перфильева, А.В.Тарсин, Г.П.Филиппов. – 2-е изд. - Ухта: УГТУ, 2002. – 67 с. ISBN 5 - 88179 - 218 - 1 Учебное пособие содержит программу, основные формулы, примеры решения задач и контрольные задания по разделам общего...»

«О.Ю.Шевченко Основы физики твердого тела Учебное пособие Санкт-Петербург 2010 МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ ФЕДЕРАЛЬНОЕ АГЕНТСТВО ПО ОБРАЗОВАНИЮ САНКТ-ПЕТЕРБУРГСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ, МЕХАНИКИ И ОПТИКИ О.Ю. Шевченко ОСНОВЫ ФИЗИКИ ТВЕРДОГО ТЕЛА Учебное пособие Санкт-Петербург 2010 1 О.Ю.Шевченко Основы физики твердого тела. Учебное пособие. – СПб: СПбГУ ИТМО, 2010. – 76с. В рамках курса общей физики рассмотрены основы физики твердого...»

«МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ САНКТ-ПЕТЕРБУРГСКИЙ НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ, МЕХАНИКИ И ОПТИКИ А.А. Усольцев ЭЛЕКТРИЧЕСКИЙ ПРИВОД Учебное пособие Санкт-Петербург 2012 Усольцев А.А. Электрический привод/Учебное пособие. СПб: НИУ ИТМО, 2012, – 238 с. Пособие содержит основные положения теории электропривода, его механики, свойств и характеристик основных типов электродвигателей, режимов работы, динамики и основ выбора мощности...»

«И. И. Ташлыкова-Бушкевич ФИЗИКА Допущено Министерством образования Республики Беларусь в качестве учебного пособия для студентов технических специальностей учреждений, обеспечивающих получение высшего образования В двух частях Часть 1 МЕХАНИКА. МОЛЕКУЛЯРНАЯ ФИЗИКА И ТЕРМОДИНАМИКА. ЭЛЕКТРИЧЕСТВО И МАГНЕТИЗМ Минск Асар 2010 УДК 53 (075.8) ББК 22.3 я 73 Т25 Р е ц е н з е н т ы: кафедра теоретической физики и астрономии Брестского государственного университета им. А.С. Пушкина, декан физического...»






 
© 2013 www.diss.seluk.ru - «Бесплатная электронная библиотека - Авторефераты, Диссертации, Монографии, Методички, учебные программы»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.