Что такое разработка компонентов?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ссылки:

• разработка компонентов и контейнер МОК

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

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

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

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

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

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

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

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

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

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

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

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

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

таким образом: Component - не является объектом. Это-функциональность объекта.

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

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

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

таким образом: компонентно-управляемая разработка дает вам:

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

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