 |
Покомпонентная разработка
|
|
|
|
Метод покомпонентной разработки ПО с повторным использованием компонентов появился в конце 1990-х годов как альтернатива объектно-ориентированному подходу к разработке систем, который не привел к повсеместному повторному использованию программных компонентов, как предполагалось изначально. Отдельные классы объектов оказались слишком детализированными и специфическими: их требовалось связывать с приложением либо во время компиляции, либо при компоновке системы. Использование классов обычно предполагает наличие детальных данных о классах, что делает доступным исходный код, но для коммерческих продуктов исходный код открыт очень редко. Несмотря на ранние оптимистические прогнозы, значительное развитие рынка отдельных программных объектов и компонентов так и не состоялось.
Компоненты более абстрактны, чем классы объектов. Поэтому их можно считать независимыми поставщиками сервисов. Если система запрашивает какой-либо сервис, вызывается компонент, предоставляющий этот сервис независимо от того, где выполняется компонент и на каком языке написан. Примером простейшего компонента может быть отдельная математическая функция, вычисляющая, например, квадратный корень числа. Для вычисления квадратного корня программа вызывает компонент, который может выполнить данное вычисление. На другом конце масштабной линейки компонентов находятся системы, которые предоставляют полный вычислительный сервис.
Взгляд на компонент как на поставщика сервисов определяется двумя основными характеристиками компонентов, допускающими их повторное использование.
1. Компонент – это независимо выполняемый программный объект. Исходный код компонента может быть недоступен, поэтому такой компонент не компилируется совместно с другими компонентами системы.
|
|
|
2. Компоненты объявляют свой интерфейс и все взаимодействия с ними осуществляются с его помощью. Интерфейс компонента описывается в терминах параметризованных операций, а внутреннее состояние компонента всегда скрыто.
Компоненты определяются через свои интерфейсы. В большинстве случаев компоненты можно описать в виде двух взаимосвязанных интерфейсов, как показано на рис. 14.2.
• Интерфейс поставщика сервисов, который определяет сервисы, предоставляемые компонентом.
• Интерфейс запросов, который определяет, какие сервисы доступны компоненту из системы, использующей этот компонент.
Рис. 14.2. Интерфейсы компонента
В качестве примера рассмотрим компонент (рис. 14.3), который предоставляет сервисы вывода документов на печать. В нашем примере поддерживаются следующие сервисы: печать документов, просмотр состояния очереди на конкретном принтере, регистрация и удаление принтеров из системы, передача документа с одного принтера на другой и удаление документа из очереди на печать. Очень важно, чтобы компьютерная платформа, на которой исполняется компонент, предоставляла сервис (назовем его ФайлОпПринтер), позволяющий извлечь файл описания принтера, и сервис КомПринтер, передающий команды на конкретный принтер.
Рис. 14.3. Компонент службы печати
Компоненты могут существовать на разных уровнях абстракции – от простой библиотечной подпрограммы до целых приложений, таких как Microsoft Excel. В работе [236] определено пять уровней абстракции компонентов.
1. Функциональная абстракция. Компонент реализует отдельную функцию, например математическую. В сущности, интерфейсом поставщика сервисов здесь является сама функция.
2. Бессистемная группировка. В данном случае компонент – это набор слабо связанных между собой программных объектов и подпрограмм, например объявлений данных, функций и т.п. Интерфейс поставщика сервисов состоит из названий всех объектов в группировке.
|
|
|
3. Абстракции данных. Компонент является абстракцией данных или классом, описанным на объектно-ориентированном языке. Интерфейс поставщика сервисов состоит из методов (операций), обеспечивающих создание, изменение и получение доступа к абстракции данных.
4. Абстракции кластеров. Здесь компонент – это группа связанных классов, работающих совместно. Такие компоненты иногда называют структурой. Интерфейс поставщика сервисов является композицией всех интерфейсов объектов, составляющих структуру (см. раздел 14.1.1).
5. Системные абстракции. Компонент является полностью автономной системой. Повторное использование абстракций системного уровня иногда называют повторным использованием коммерческих продуктов. Интерфейсом поставщика сервисов на этом уровне является так называемый программный интерфейс приложений (Application Programming Interface – API), который предоставляет доступ к системным командам и методам. Повторное использование коммерческих продуктов рассматривается в разделе 14.1.2.
Подход покомпонентной разработки систем можно интегрировать в общий процесс создания ПО путем добавления специальных этапов, на которых отбираются и адаптируются повторно используемые компоненты (рис. 14.4). Проектировщики системы разрабатывают системную архитектуру на высоком уровне абстракции, составляя спецификации системных компонентов. В дальнейшем эти спецификации используются для поиска повторно используемых компонентов. Они включаются в систему либо на уровне системной архитектуры, либо на более низких детализированных уровнях.
Рис. 14.4. Интеграция повторного использования компонентов в процесс разработки ПО
Хотя такой подход может привести к значительному увеличению количества повторно используемых компонентов, он, в сущности, противоположен подходу, применяемому в других инженерных дисциплинах, где процесс проектирования подчинен идее повторного использования. Перед началом этапа проектирования разработчики выполняют поиск компонентов, подходящих для повторного использования. Системная архитектура строится на основе уже имеющихся (готовых) компонентов (рис. 14.5).
|
|
|
Рис. 14.5. Процесс проектирования с повторным использованием компонентов
В данном случае требования к системе изменяются с учетом имеющихся компонентов, выбранных для повторного использования. Системная архитектура также базируется на имеющихся компонентах. Конечно, такой подход предполагает определенные компромиссы в реализации требований. Хотя такая система может оказаться менее эффективной, чем система, разработанная без повторного использования компонентов, этот недостаток компенсируется более низкой стоимостью разработки, более высокими темпами создания системы и ее повышенной надежностью.
Обычно покомпонентный процесс реализации системы является либо процессом макетирования (прототипирования), либо процессом пошаговой разработки. Вместе с библиотеками компонентов можно использовать стандартные языки программирования, например Java. Альтернативой ему (и более распространенным языком) является язык сценариев, который специально разработан для интегрирования повторно используемых компонентов и обеспечивает быструю разработку программ.
Первым языком сценариев, разработанным для интеграции повторно используемых компонентов, был Unix shell [56]. После него разработано множество других языков сценариев, например Visual Basic и TCL/TK. В работе [268] обсуждаются преимущества языков сценариев, в том числе отсутствие определения типов данных, и тот факт, что они не компилируются, а интерпретируются.
Пожалуй, главной проблемой, связанной с покомпонентной разработкой систем, является их сопровождение и модернизация. При изменении требований к системе часто в компоненты необходимо внести изменения, соответствующие новым требованиям, однако в большинстве случаев это невозможно, поскольку исходный код компонентов недоступен. Также, как правило, не подходит альтернативный вариант: замена одного компонента другим. Таким образом, необходима дополнительная работа по адаптации повторно используемых компонентов, что приводит к повышению стоимости обслуживания системы. Однако, поскольку разработка с повторным использованием компонентов позволяет быстрее создавать ПО, организации согласны оплачивать дополнительные расходы на сопровождение и модернизацию систем.
|
|
|
