Компонентно-ориентированная архитектура

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

Основная задача архитектуры на основе компонентов заключается в обеспечении возможности повторного использования компонентов . Компонент инкапсулирует функциональность и поведение программного элемента в повторно используемую и самораскрывающуюся двоичную единицу. Существует множество стандартных компонентов, таких как COM / DCOM, JavaBean, EJB, CORBA, .NET, веб-сервисы и сеточные сервисы. Эти технологии широко используются в проектировании приложений GUI для локальных компьютеров, таких как графические компоненты JavaBean, компоненты MS ActiveX и компоненты COM, которые можно повторно использовать простым перетаскиванием.

Компонентно-ориентированное проектирование программного обеспечения имеет много преимуществ по сравнению с традиционными объектно-ориентированными подходами, такими как —

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

• Повышенная надежность благодаря повторному использованию существующих компонентов.

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

Повышенная надежность благодаря повторному использованию существующих компонентов.

Что такое компонент?

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

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

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

Представления компонента

Компонент может иметь три различных представления — объектно-ориентированное представление, обычное представление и представление, связанное с процессом.

Объектно-ориентированный вид

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

Обычный вид

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

Процессное представление

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

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

• Другие распространенные типы компонентов — это ресурсоемкие, не часто используемые компоненты, которые должны быть активированы с использованием подхода JIT.

• Многие компоненты являются невидимыми, которые распространяются в корпоративных бизнес-приложениях и интернет-веб-приложениях, таких как Enterprise JavaBean (EJB), компоненты .NET и компоненты CORBA.

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

Другие распространенные типы компонентов — это ресурсоемкие, не часто используемые компоненты, которые должны быть активированы с использованием подхода JIT.

Многие компоненты являются невидимыми, которые распространяются в корпоративных бизнес-приложениях и интернет-веб-приложениях, таких как Enterprise JavaBean (EJB), компоненты .NET и компоненты CORBA.

Характеристики компонентов

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

• Заменяемые — компоненты могут быть свободно заменены другими аналогичными компонентами.

• Не зависит от контекста — Компоненты предназначены для работы в разных средах и контекстах.

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

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

• Независимо — компоненты разработаны так, чтобы иметь минимальные зависимости от других компонентов.

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

Заменяемые — компоненты могут быть свободно заменены другими аналогичными компонентами.

Не зависит от контекста — Компоненты предназначены для работы в разных средах и контекстах.

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

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

Независимо — компоненты разработаны так, чтобы иметь минимальные зависимости от других компонентов.

Принципы компонентно-ориентированного проектирования

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

• Система программного обеспечения разделена на многократно используемые, связные и инкапсулированные компоненты.

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

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

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

• Соединители соединяют компоненты, определяя и управляя взаимодействием между компонентами. Тип взаимодействия определяется интерфейсами компонентов.

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

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

• Компонент может распространяться на другие компоненты и по-прежнему предлагать свои собственные точки расширения. Это концепция архитектуры на основе плагинов. Это позволяет плагину предлагать другой плагин API.

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

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

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

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

Соединители соединяют компоненты, определяя и управляя взаимодействием между компонентами. Тип взаимодействия определяется интерфейсами компонентов.

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

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

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

Руководство по проектированию на уровне компонентов

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

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

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

• Признает и обнаруживает эти независимые объекты в качестве новых компонентов.

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

• Моделирует любые зависимости слева направо и наследование сверху (базовый класс) и снизу (производные классы).

• Моделируйте любые зависимости компонентов как интерфейсы, а не представляйте их как прямую зависимость между компонентами.

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

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

Признает и обнаруживает эти независимые объекты в качестве новых компонентов.

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

Моделирует любые зависимости слева направо и наследование сверху (базовый класс) и снизу (производные классы).

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

Проведение проектирования на уровне компонентов

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

Распознает все классы проектирования, которые соответствуют области инфраструктуры.

Описывает все классы дизайна, которые не получены как повторно используемые компоненты, и указывает детали сообщения.

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

Подробно описывает процесс обработки внутри каждой операции с помощью псевдокода или диаграмм действий UML.

Описывает постоянные источники данных (базы данных и файлы) и определяет классы, необходимые для управления ими.

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

Разрабатывает схемы развертывания для предоставления дополнительных деталей реализации.

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

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

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

Снижение затрат — использование сторонних компонентов позволяет распределить затраты на разработку и обслуживание.

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

Многоразовое использование — использование повторно используемых компонентов означает, что их можно использовать для распределения затрат на разработку и обслуживание по нескольким приложениям или системам.

Модификация технической сложности — компонент изменяет сложность посредством использования контейнера компонента и его сервисов.

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

Обслуживание и развитие системы — Легко изменить и обновить реализацию, не затрагивая остальную часть системы.

Независимость — независимость и гибкость подключения компонентов. Самостоятельная разработка компонентов по разным группам параллельно. Производительность для разработки программного обеспечения и будущей разработки программного обеспечения.