Что такое Управляемая Компонентом Разработка?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ, который вы ищете, вероятно, будет найден в Почему и что из Inversion of Control Ке Джин.

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

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

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

Согласно Википедии, Component-Based Development - это псевдоним для Component-based software engineering (CBSE) .

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

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

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

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

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

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

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

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

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

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

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

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

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

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