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

Ответ 1

Что это?

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

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

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

Когда это подходит, а когда нет?

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

Ответ 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

alt text http://upload.wikimedia.org/wikipedia/en/2/25/Component-based_Software_Engineering_%28CBSE%29_-_example_2.gif

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

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

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

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

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

Ответ 3

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

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

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

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

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

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

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

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

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

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

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

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

Ответ 7

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

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

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

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

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

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

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

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

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

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