Парадигмы программирования |
---|
|
Компонентная разработка программного обеспечения ( CBSE ), также называемая разработкой на основе компонентов ( CBD ), - это отрасль программной инженерии, которая подчеркивает разделение задач в отношении широких функциональных возможностей, доступных в данной программной системе . Это основанный на повторном использовании подход к определению, реализации и составлению слабосвязанных независимых компонентов в системы. Эта практика направлена на получение одинаково широких преимуществ как в краткосрочной, так и в долгосрочной перспективе как для самого программного обеспечения, так и для организаций, спонсирующих такое программное обеспечение.
Практики программной инженерии рассматривают компоненты как часть стартовой платформы для ориентации на сервисы . Компоненты играют эту роль, например, в веб-сервисах , а с недавних пор и в сервис-ориентированных архитектурах (SOA), посредством чего компонент преобразуется веб-сервисом в сервис и впоследствии наследует другие характеристики, помимо характеристик обычного компонента.
Компоненты могут создавать или потреблять события и могут использоваться для архитектур, управляемых событиями (EDA).
Отдельный программный компонент - это программный пакет , веб-сервис , веб-ресурс или модуль, который инкапсулирует набор связанных функций (или данных).
Все системные процессы помещены в отдельные компоненты, так что все данные и функции внутри каждого компонента связаны семантически (как и с содержимым классов). Из-за этого принципа часто говорят, что компоненты являются модульными и связными .
Что касается общесистемной координации, компоненты взаимодействуют друг с другом через интерфейсы . Когда компонент предлагает услуги остальной части системы, он принимает предоставленный интерфейс, который определяет службы, которые могут использовать другие компоненты, и способы их выполнения. Этот интерфейс можно рассматривать как подпись компонента - клиенту не нужно знать о внутренней работе компонента (реализации), чтобы использовать его. Этот принцип приводит к тому, что компоненты называются инкапсулированными . Иллюстрации UML в этой статье представляют предоставленные интерфейсы с помощью символа леденца на палочке, прикрепленного к внешнему краю компонента.
Однако, когда компоненту необходимо использовать другой компонент для работы, он принимает используемый интерфейс, который определяет необходимые ему службы. На иллюстрациях UML в этой статье используемые интерфейсы представлены символом открытого сокета, прикрепленным к внешнему краю компонента.
Другим важным атрибутом компонентов является то, что они являются заменяемыми , так что компонент может заменять другой (во время разработки или во время выполнения), если компонент-преемник удовлетворяет требованиям исходного компонента (выраженным через интерфейсы). Следовательно, компоненты могут быть заменены либо обновленной версией, либо альтернативой, не нарушая работу системы, в которой работает компонент.
Как показывает опыт инженеров, заменяющих компоненты, компонент B может немедленно заменить компонент A, если компонент B предоставляет хотя бы то, что предоставил компонент A, и использует не больше, чем использованный компонент A.
Программные компоненты часто принимают форму объектов (не классов ) или коллекций объектов (из объектно-ориентированного программирования ), в некоторой двоичной или текстовой форме, придерживаясь некоторого языка описания интерфейса (IDL), так что компонент может существовать автономно от других компонентов. в компе . Другими словами, компонент действует без изменения исходного кода. Хотя поведение исходного кода компонента может измениться в зависимости от расширяемости приложения, обеспечиваемой его автором.
Когда к компоненту необходимо получить доступ или совместно использовать его в контексте выполнения или сетевых связях, для доставки компонента в пункт назначения часто используются такие методы, как сериализация или маршаллинг .
Возможность повторного использования - важная характеристика высококачественного программного компонента. Программисты должны разрабатывать и реализовывать программные компоненты таким образом, чтобы их можно было повторно использовать во многих различных программах. Кроме того, следует рассмотреть возможность тестирования удобства использования на основе компонентов, когда компоненты программного обеспечения напрямую взаимодействуют с пользователями.
Чтобы написать программный компонент, который можно было бы эффективно повторно использовать, требуются значительные усилия и осведомленность. Компонент должен быть:
В 1960-х программисты создали научные библиотеки подпрограмм, которые можно было многократно использовать в широком спектре инженерных и научных приложений. Хотя эти библиотеки подпрограмм эффективно повторно использовали четко определенные алгоритмы , их область применения была ограничена. Коммерческие сайты обычно создавали прикладные программы из многократно используемых модулей, написанных на ассемблере , COBOL , PL / 1 и других языках второго и третьего поколения, используя как системные, так и пользовательские библиотеки приложений.
По состоянию на 2010 год [Обновить]современные повторно используемые компоненты инкапсулируют как структуры данных, так и алгоритмы, которые применяются к структурам данных. Компонентная разработка программного обеспечения основывается на предшествующих теориях программных объектов , архитектур программного обеспечения , программных средах и шаблонах проектирования программного обеспечения , а также на обширной теории объектно-ориентированного программирования и объектно-ориентированного проектирования всего этого. Он утверждает, что программные компоненты, такие как аппаратные компоненты , используемые, например, в телекоммуникациях, [1]в конечном итоге можно сделать взаимозаменяемыми и надежными. С другой стороны, утверждается, что было бы ошибкой сосредотачиваться на независимых компонентах, а не на структуре (без которой они не существовали бы). [2]
Идея о том, что программное обеспечение должно быть разбито на компоненты - построено из готовых компонентов - впервые стала заметной в выступлении Дугласа Макилроя на конференции НАТО по разработке программного обеспечения в Гармише , Германия , 1968 г., под названием « Компоненты программного обеспечения массового производства» . [3] Конференция была призвана противостоять так называемому кризису программного обеспечения . Последующее включение Макилроем каналов и фильтров в операционную систему Unix было первой реализацией инфраструктуры для этой идеи.
Брэд Кокс из Stepstone во многом определил современную концепцию программного компонента. [4] Он назвал их программными ИС и намеревался создать инфраструктуру и рынок для этих компонентов, изобретя язык программирования Objective-C . (Он резюмирует этот взгляд в своей книге « Объектно-ориентированное программирование - эволюционный подход» 1986 года.)
Программные компоненты используются в двух разных контекстах и двух видах: i) использование компонентов в качестве частей для создания единого исполняемого файла или ii) каждый исполняемый файл рассматривается как компонент в распределенной среде, где компоненты взаимодействуют друг с другом через Интернет или интрасеть. протоколы связи для IPC (Inter Process Communications). Вышеупомянутое относится к первому виду, а нижнее - к более позднему.
IBM в начале 1990-х гг. Стала лидером в разработке своей системной объектной модели (SOM) . В ответ Microsoft проложила путь к фактическому развертыванию компонентного программного обеспечения с помощью связывания и внедрения объектов (OLE) и модели компонентных объектов (COM). [5] По состоянию на 2010 год существует [Обновить]множество успешных моделей компонентов программного обеспечения.
Компьютер, на котором запущено несколько программных компонентов, часто называют сервером приложений . Такое сочетание серверов приложений и программных компонентов обычно называют распределенными вычислениями . Типичное практическое применение этого -, например, в финансовых приложениях или программном обеспечении для бизнеса.
Компонент модели является определение свойств, компоненты должны удовлетворять, методы и механизмы для состава компонентов. [6]
В течение последних десятилетий исследователи и практики предложили несколько компонентных моделей с разными характеристиками. Классификация существующих компонентных моделей приведена в. [6] [7] Примеры компонентных моделей: модель Enterprise JavaBeans (EJB), модель компонентной объектной модели (COM), модель .NET , компонентная модель X-MAN, [8 ] и компонентной модели Common Object Request Broker Architecture (CORBA).
Этот раздел имеет формат списка , но может читаться лучше как проза . ( Январь 2020 г. ) |
System.ComponentModel
имен в Microsoft .NETКомпонент не существует
Современная концепция программного компонента во многом определена Брэдом Коксом из Stepstone => язык программирования Objective-C
1990, IBM изобретает свою системную объектную модель.
1990, как реакция, Microsoft выпустила OLE 1.0 OLE custom controls (OCX)[ постоянная мертвая ссылка ]