Интернет магазин китайских планшетных компьютеров

Компьютеры - Аспектно-ориентированная разработка программного обеспечения - Цели

Скозные проблемы

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

Говорят, что реализация проблемы рассеяна, если его код рассредоточен по многим модулям. В результате проблема влияет на реализацию многих модулей и соответственно её реализация не является модульной.

Говорят, что реализация проблемы запутана, если её код смешан с кодом, который реализует другие проблемы. Модуль, в котором происходит путаница, не связен.

Рассеивание и путаница часто возникают вместе, хотя они они - различные понятия.

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

Примеры сквозных проблем

• Синхронизация
• Работа в реальном времени
• Обнаружение и исправление ошибок
• Особенности продукта
• Менеджер памяти
• Проверка данных
• Персистентность
• Обработка транзакций
• Информационная безопасность
• Кэширование
• Ведение логов
• Мониторинг
• Бизнес-логика
• Переносимые программы
• Интернационализация и Локализация
• Некоторые виды оптимизации

Проблемы возникающие при рассеянии и путанице

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

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

Системная разработка

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

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

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

Наконец, проблемы, которые не выделены в модули, трудно протестировать в отдельности. Зависимости проблемы относительно поведения других модулей явно не описаны. Следовательно, реализация теста для таких проблем требует знания о реализации многих модулей в системе.

Обслуживание системы и развитие

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