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

Question

Разработка, основанная на компонентах термин начинает широко использоваться, особенно.в связи с Инверсией Управления.

1. Что это?
2. Какие проблемы это решает?
3. Когда это уместно, а когда нет?

Answer 1

Что это?

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

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

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

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

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

Answer 2

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

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

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

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

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

• Графический интерфейс ПОЛЬЗОВАТЕЛЯ
• пусковая установка
• диспетчер (для отправки вычислений по нескольким серверам, потому что у одного не хватило бы памяти, чтобы вычислить все!)
• и так далее

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

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

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

Answer 3

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

Ответ, который вы ищете, скорее всего, будет найден в Почему и что происходит с Инверсией контроля автор: Ке Чжин.

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

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

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

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

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

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

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

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

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

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

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

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

_{(источник: wikimedia.org)}

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

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

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

Answer 6

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

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

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

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

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

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

Answer 7

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

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

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

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

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

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

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

Таким образом:Разработка, основанная на компонентах, дает вам:

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

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