Что такое разработка, основанная на компонентах?

Что это?

Я думаю, что определение в вашем ответе хорошо освещает этот вопрос. Хотя, я сомневаюсь, почему определение включает в себя, что компонент должен явно определять свои зависимости. Канонический пример компонента – это элемент управления ActiveX – нужно ли им явно определять свои зависимости?

Какие проблемы он решает?

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

Когда это уместно, а когда нет?

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

Я не уверен, что это «широко распространенная» терминология, но в VCS (Version Control System) я знаю два способа управления набором файлов, необходимых для создания программы:

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

Прикладная архитектура используется для идентификации этих компонентов:

• функциональный домен и приложения
• сторонние библиотеки
• frameworks

Вот где IoC входит, поскольку он лежит в основе любой структуры. Проблема, которую он решает, позволяет лучше определить часть вашего приложения:
Предположим, вы разработали приложение PLR (Profit and Loss), отвечающее за вычисление прибыли и убытков (позиции) трейдера.
Вы бы быстро поняли, что это не одно приложение, а состав нескольких:

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

Затем вы можете определить структуру вычислений (Ioc), которая позволит вам подключать ваши различные модули, которые затем вызывается в нужное время вашей инфраструктурой.

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

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

Разработка на основе компонентов не является чем-то новым. Я не знаю разработки, основанной на компонентах, но я собираюсь предположить, что это CBD. Именно так разрабатывается Unix, набор замещаемых небольших программ, каждый из которых делает одну вещь очень хорошо. На настольной арене VCL Delphi успешно использует компоненты с богатыми многоразовыми компонентами и сторонним рынком, как никто другой. Сейчас мы видим возрождение КБР, поскольку некоторые технологии созревают. Например, простые веб-приложения развиваются в SOA и RESTful WS. Все ребята из Java говорили о модульности и IoC.

Ответ, который вы, скорее всего, ищете, можно найти в разделе «Почему» и «Инверсия контроля » Ке Цзинь.

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

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

Структуры CBD, которые объединяют описания декларативных приложений и технологию IoC, называются структурами IoC. В отличие от своих предшественников, frameworks IoC не являются инвазивными и используют сценарий вложения / настройки зависимости / конфигурации .

Согласно Wikipedia, разработка на основе компонентов – это псевдоним для разработки программного обеспечения на основе компонентов (CBSE) .

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

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

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

Все системные процессы помещаются в отдельные компоненты, так что все данные и функции внутри каждого компонента семантически связаны (как и с содержимым classов). Из-за этого принципа часто говорят, что компоненты являются модульными и сплоченными .

Таким образом, согласно этому определению, компонент может быть любым, если он делает что-то очень хорошо и только одно.

Что касается общесистемной координации, компоненты взаимодействуют друг с другом через интерфейсы . […] Этот принцип приводит к компонентам, которые называются инкапсулированными .

Так что это все больше напоминает то, что мы думаем о хорошем API или SOA.

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

alt text http://sofru.miximages.com/inversion-of-control/Component-based_Software_Engineering_(CBSE)_-_example_2.gif

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

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

Подставляемость и повторное использование – вот что делает компонент компонентом. Так в чем же разница между этим и объектно-ориентированным программированием?

Идея в объектно-ориентированном программировании (ООП) заключается в том, что программное обеспечение должно быть написано в соответствии с ментальной моделью реальных или воображаемых объектов, которые она представляет. […]

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

Вот мое определение после некоторых исследований.

Разработка компонентов – это подход к разработке программного обеспечения, в котором fragment кода fragmentирован в многоразовые и тестируемые компоненты, которые объединены вместе, чтобы сформировать основу приложения для предоставления бизнес-функций. Комбинация и управление компонентами обычно делегируется Inversion of Control Container.

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

Ссылки по теме:

• Разработка компонентов и контейнер IoC

Я рассматриваю компонентную программную инженерию как подход к разработке программных систем с использованием подключаемых компонентов; с компонентом, являющимся « единицей композиции с контрактными интерфейсами и явными контекстными зависимостями », которые « могут быть развернуты независимо и подчинены третьей стороне ». (Clemens Szyperski, « Компонентное программное обеспечение: вне объектно-ориентированного программирования »)

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

Есть существенные исследования, которые были посвящены этой теме в течение многих лет. Ведущее событие ( симпозиум ACM SIGSOFT по разработке программного обеспечения на основе компонентов ) находится на 14-м году, и появилось немало новых тенденций.

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

Если вы заинтересованы в объединении компонентов (или других многоразовых активов) в приложения, вы также должны ознакомиться с методологией линейки программных продуктов .

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

• Эти два компонента не должны использоваться вместе (взаимная эксклюзивность)
• Если этот компонент используется, то этот другой компонент должен использоваться или (взаимозависимость)
• Может использоваться любая комбинация некоторого определенного набора компонентов (опциональность)

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

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

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

Вы никогда не поймете, что на самом деле представляет собой компонентное развитие, пока вы не попытаетесь использовать Unity 3D. Это не ActiveX или что-либо, что вы когда-либо видели раньше, то, что вы видели раньше, имеет другое значение Component.

Разработка с использованием компонентов, о каждом разговоре в последнее время, означает, что у вас есть 2 вещи:

1. Объект, который похож на объект в программировании ООП или объекте реального мира.
2. Компонент объекта – который похож на функциональность объекта или его способность.

Таким образом: Компонент – это не объект. Это – Функциональность объекта .

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

В разработке с компонентами, когда вам нужен расширенный объект, вы просто создаете пустой объект и заполняете его различными компонентами без наследования. В разработке, основанной на компонентах, нет classов, вместо этого есть Prefabs – это предопределенные объекты с предопределенными компонентами с дочерними объектами.

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

Таким образом: Разработка с использованием компонентов дает вам:

1. Великая сила для создания логики вашей программы, используя только редактор, без программирования.
2. Освобождает ваш разум от афоризма ООП. Делает разработку более простой и быстрой.
3. Делает вашу программу очень настраиваемой и масштабируемой, даже не касаясь кода. Меньше ошибок и ошибок.
4. Проще всего сохранить код вашей программы, просто перепрограммируя определенные компоненты, не оказывая большого влияния на систему restа.
5. и т.д…

Я также хочу добавить, что программирование на основе компонентов (управляемое) не является заменой для программирования ООП, оно находится на вершине ООП или обычного программирования. Обычное программирование, все еще используемое в CBP для реализации Компонента низкого уровня. Я думаю, что в этой статье также есть хорошее и краткое объяснение CBP: http://acmantwerp.acm.org/wp-content/uploads/2010/10/componentbasedprogramming.pdf