Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
KNit-09_zach_Otvety.docx
Скачиваний:
0
Добавлен:
01.05.2025
Размер:
137.89 Кб
Скачать

Компонентный подход к проектированию

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

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

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

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

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

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

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

Методология компонентной разработки систем включает в себя две основные фазы процесса разработки:

1. Разработка отдельных компонентов;

2. Интеграция (композиция) компонентов в более сложные программные образования.

6.///////////////////////////////////////////6///////////////////////////////////////6/////////////////////////////////////////6////////////////////////////////6/////////////////////////////////6/////////////////////////////6

Аспектно–ориентированное программирование (аоп).

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

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

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

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

7//////////////////////////7/////////////////////////////7/////////////////////////////7/////////////////////////////////////////////////7///////////////////////////////////////////7////////////////////////////////////////////7

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]