Андон Ф.И., Коваль Г.И., Коротун Т.М., Лаврищева Е.М., Суслов В.Ю. Основы инженерии качества программных систем

Подождите немного. Документ загружается.

94 Глава 2

программ (основанных на принципах согласования и параллелизма) требуют от-

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

2.5.4. Парадигма объектно-ориентированного программирования

Из «недр» событийно-управляемого программирования появилось и объект-

но-ориентированное программирование, оказавшись значительно более мощным и

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

Объектно-ориентированное программирование (ООП) – парадигма, основан-

ная на представлении предметной области в виде системы взаимосвязанных абст-

рактных объектов и их реализаций.

В парадигме объектно-ориентированного программирования различают два

стиля – программирование, основанное на классах (class-based programming), и про-

граммирование, основанное на прототипах (prototype-based programming).

Программирование «на классах». В отличие от стиля процедурного про-

граммирования, в котором данные и функции их обработки не связаны, в этом сти-

ле определена новая структура данных - класс - по сути дела это тип объекта, в ко-

тором кроме данных (свойств, параметров объекта) содержатся функции их обра-

ботки (методы, допустимые действия объекта или с объектом).

Объект по отношению к своему классу является экземпляром. Класс опреде-

ляет структуру и функциональность (поведение), одинаковую для всех экземпляров

данного класса. Один класс отличается от других именем и, обычно, набором под-

держиваемых интерфейсов. Интерфейсы, в свою очередь, представляют собой на-

бор сообщений, которые можно посылать объекту. Экземпляр является носителем

данных, то есть обладает состоянием, меняющимся в соответствии с поведением,

заданным классом. В языках ООП новый экземпляр создается через вызов конст-

руктора класса (возможно, с набором параметров). Получившийся экземпляр имеет

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

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

объектом сообщения запускается соответствующий ему обработчик (метод). Объ-

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

ный метод для обработки. Если метод для обработки сообщения не найден, сооб-

щение перенаправляется объекту-предку.

Важнейшими принципами ООП являются:

наследование - механизм установления отношений «потомок-предок» (воз-

можность порождать один класс от другого с сохранением всех свойств и методов

класса-предка),

инкапсуляция (свойство сокрытия реализации (поведения) класса),

абстракция (описание взаимодействия исключительно в терминах сообще-

ний/событий в предметной области),

полиморфизм (возможность подмены в сценарии взаимодействия объектов

одного объекта другим объектом со сходной структурой).

Многие современные языки специально созданы для программирования на

классах, например, Smalltalk, С++, Java, Python, PHP, Object Pascal (Delphi),

VB.NET, Xbase++ и др. Однако следует отметить, что можно применять приемы

ООП и для не-объектно-ориентированного языка и наоборот, применение объект-

но-ориентированного языка еще не означает, что код автоматически становится

объектно-ориентированным. В наши дни парадигма объектно-ориентированного

Глава 2 95

программирования на классах активно используется при проектировании сложных

систем и моделировании, например, в языке UML.

Для ПС, создаваемых в представленном стиле программирования, в инжене-

рии качества наработаны и методы тестирования, и метрики, и способы прогнози-

рования размера и сложности.

Программирование по прототипу

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

тие класса отсутствует, а повторное использование (наследование) производится

путем клонирования существующего экземпляра объекта — прототипа.

В отличие от стиля программирования, основанного на классах и концентри-

рующего внимание разработчика на таксономии классов и на отношениях между

ними, стиль прототипного программирования заостряет внимание на поведении

небольшого количества «образцов», которые далее используются как «базовые»

объекты для создания других объектов.

Создание нового объекта выполняется одним из двух методов: путем клони-

рования существующего объекта, либо путем создания объекта «с нуля». Для соз-

дания объекта с нуля предоставляются синтаксические средства добавления

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

получена полная копия, клон. В процессе клонирования копия наследует все харак-

теристики своего прототипа, но с этого момента становится самостоятельной и мо-

жет быть изменена. В некоторых реализациях копии хранят ссылки на объекты-

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

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

тают полную независимость от своих прототипов: прототип копируется один-в-

один, со всем методами и атрибутами, и копии присваивается новое имя (ссылка).

Преимущество данного подхода состоит в том, что создатель копии может ее ме-

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

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

как нет необходимости обходить всю цепочку возможных делегатов в поисках под-

ходящего метода или атрибута. В числе недостатков - трудности с распространени-

ем изменений в системе: модификация прототипа не влечет за собой немедленное и

автоматическое изменение всех его потомков. Другой недостаток состоит в том,

что простейшие реализации этой модели приводят к увеличенному (по сравнению с

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

копию данных своего прототипа до тех пор, пока не будет изменен.

Каноническим примером прототипного языка является язык Self. Прототип-

ный стиль программирования положен также в основу таких языков программиро-

вания, как JavaScript, Squeak, Cecil, NewtonScript, Io, MOO, REBOL, Kevo и др.

Прототипно-ориентированные системы сравнительно новы и немногочис-

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

работки пока не определены.

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

Чаще всего парадигма декларативного (повествовательного, описательного)

программирования ассоциируется со стилями и каноническими языками функцио-

нального программирования (например, Lisp), логического программирования

Источник информации – энциклопедия Википедия (http://ru.wikipedia.org/wiki)

96 Глава 2

(Prolog) или программирования в ограничениях (Oz), и противопоставляется пара-

дигме императивного (повелительного, командного) программирования [28].

Однако декларативным является и описание Web-страниц на HTML и XML-

документов (в проблематике Web-технологий), и описание структур таблиц БД на

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

ния также относят к декларативному, а языки называют доменными (специализиро-

ванными для определенных доменов (областей применения)) или DSL-языками

(Domain Specific Languages).

В программе, разрабатываемой в парадигме декларативного программирова-

ния, четко формулируется цель и результат ее работы, а не алгоритм получения

этого результата. Для обработки описанных структур данных используются стан-

дартные алгоритмы реализующих систем этих языков. Например, при создании

Web-страницы средствами HTML специфицируется, каким образом должна выгля-

деть страница, а трансляция этой спецификации в пиксельное представление вы-

полняется с помощью процедурного алгоритма браузера. DSL-языки иногда

встраиваются в универсальные языки, хотя писать программы в декларативном

стиле можно и с помощью императивных языков, инкапсулируя «не декларатив-

ные» детали в библиотечные компоненты.

Функциональное программирование. В отличие от императивного програм-

мирования, где алгоритмы - это описания последовательно исполняемых операций,

существует понятие текущего шага исполнения (во времени), и текущего состоя-

ния, изменяющегося с течением этого времени, в функциональном программирова-

нии понятие времени отсутствует.

Как и другие стили «неимперативного» программирования, функциональное

программирование (functional programming) применяется для решения задач, труд-

но формулируемых в терминах последовательных операций – преимущественно

задач, связанных с распознаванием образов, общением на естественном языке, реа-

лизацией экспертных систем, автоматизированным доказательством теорем, сим-

вольными вычислениями.

Функциональное программирование опирается на теории лямбда-исчисления

(Алонзо Черча) и комбинаторной логики (Мозеса Шенфинкеля и Хаскелла Карри).

Функциональная программа состоит из совокупности определений функций, пред-

ставляющих собой вызовы других функций, и предложений, управляющих после-

довательностью вызовов. Описание зависимости функций друг от друга (возможно

рекурсивной) фактически определяет способ решения задачи (без указания после-

довательности шагов). Рекурсия является фундаментальной основой построения

семантики языков функционального программирования. В общем случае, функ-

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

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

вычисления ее значения. Разветвление вычислений основано на механизме обра-

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

с помощью рекурсии.

Наиболее известны следующие функциональные языки программирования:

–

LISP (1958 год) и множество его потомков, наиболее современные из ко-

торых - Scheme и Common Lisp,

–

ML (1979 год) и его наиболее известные диалекты - Standard ML и

Objective CAML,

Глава 2 97

–

Miranda (1985), который дал развитие языку Haskell и др.

Языки функционального программирования в основном используются в на-

учных (академических), а не в коммерческих приложениях, за исключением языка

Erlang (для разработки высокопроизводительных приложений в телекоммуника-

ции), языков J and K (для финансового анализа), а также таких доменных языков,

как, например, XSLT.

Логическое программирование. В логическом программировании (logic или

logical programming) программа представляет собой некоторую теорию (описан-

ную на достаточно ограниченном языке), и утверждение, которое нужно доказать.

Теория задается с помощью аксиом и правил вывода. Утверждение, которое требу-

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

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

представляющей собой совокупность определенных фактов и правил.

Если в функциональном программировании функции однонаправлены - по-

лучают аргументы и возвращают результат, в логическом программировании раз-

ница между вводом и выводом условна. Можно указать желаемый вывод и полу-

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

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

зом, поскольку произвольное целевое утверждение может быть доказано не един-

ственным образом, система, реализующая язык логического программирования

(например, Prolog), последовательно предлагает возобновить попытку доказать ут-

верждение по-другому. Для доказательства утверждений используется унификация

(сопоставление двух произвольных термов) и метод резолюций.

В логическом программировании, также как и в функциональном програм-

мировании, программист остается в неведении о методах вычислений, и последова-

тельности элементарных действий. Большая часть ответственности за их эффек-

тивность возлагается на транслятор используемого языка программирования. В на-

стоящее время существует несколько «промышленных» реализаций языка Prolog,

причем исполняемый код, порождаемый транслятором, как правило, сопоставим по

эффективности с кодом аналогичной программы на императивных языках.

Логическое программирование оказалось эффективно не только в реализации

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

описания сложных систем, например, диспетчерских систем

Программирование в ограничениях [22]. Программирование в ограничениях

(constraint programming) - это программирование в терминах постановок задач, где

постановка задачи – это конечный набор переменных V = {v

, ..., v

}, соответст-

вующих им конечных (перечислимых) множеств значений DV = {dv

,...,dv

}, и на-

бор ограничений C = {c

,...,c

}. Система ограничений может включать в себя урав-

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

конструкции, связывающие переменные из набора V. Решение задачи состоит в по-

строении набора значений переменных, удовлетворяющего всем ограничениям c

где i = 1,.., m.

Программирование в ограничениях тесно связано с традиционным логиче-

ским программированием. Большинство систем программирования в ограничениях

представляют собой интерпретатор языка Prolog со встроенным механизмом для

Известно, что диспетчерская система лондонского аэропорта Хитроу в настоящий

момент переписывается на языке Prolog.

98 Глава 2

решения определенного класса задач удовлетворения ограничениям. Программиро-

вание в таких системах называют логическим программированием в ограничениях

(Constraint Logic Programming или CLP), а большинство языков или библиотек на-

зываются CLP(X), где X указывает на класс решаемых задач. Например, CLP(B)

означает возможность решать уравнения с булевыми переменными, CLP(Q) – урав-

нения в рациональных числах, а CLP(R) – в вещественных. Наиболее популярны

решатели задач на конечных множествах целых чисел CLP(FD).

Семантически программирование в ограничениях отличается от традицион-

ного логического программирования в первую очередь тем, что исполнение про-

граммы рассматривается не как доказательство утверждения, а как нахождение

значений переменных. При этом внутренний порядок решения не имеет значения

для выполнения отдельных ограничений и система программирования в ограниче-

ниях, как правило, стремится оптимизировать порядок доказательства утверждений

с целью минимизации отката в случае неуспеха. Любая логическая программа мо-

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

Иногда логические программы специально конвертируют в программы с ограниче-

ниями, поскольку выполнить решение задачи с ограничениями бывает проще, чем

произвести логический вывод программы.

Наиболее популярными языками программирования в ограничениях являют-

ся языки, базирующиеся на Prolog: B-Prolog, CHIP V5, Ciao Prolog, ECLiPSe, GNU

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

императивного программирования путем подключения библиотек функций (на-

пример, библиотек функций Java, C++).

Доказательное программирование и синтез программ [29]. Чтобы быть

уверенным в том, что программа работает правильно, лучше всего иметь доказа-

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

либо строить программы параллельно с доказательством их правильности (синте-

зировать заведомо правильные программы). Практика показала, что во втором

случае программы получаются яснее, изящнее и зачастую эффективнее, чем про-

граммы, написанные бессистемно.

Условие задачи при синтезирующем программировании записывается в виде

спецификации задачи. В последующем синтезе программы по спецификациям раз-

личают два подхода: логический и аналитический.

При логическом подходе спецификация трактуется как формулировка теоре-

мы, утверждающей существование решения задачи. Синтез программы состоит в

поиске доказательства этой теоремы существования в некотором конструктивном

логическом исчислении. Если такое доказательство удается построить, то исполь-

зуются формальные правила, позволяющие преобразовать доказательство в про-

грамму, находящую решение задачи. Существует универсальная контролирующая

процедура, которая проверяет правильность доказательства и применения правил

перехода от доказательства к программе.

При аналитическом подходе спецификация трактуется как уравнение относи-

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

ваниям, при которых символ неизвестной программы «рассыпается» на систему

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

неизвестными, либо конкретными программными конструкциями. Таким образом,

по мере преобразования синтезируемая программа постепенно превращается в за-

Глава 2 99

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

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

2.5.6. Парадигмы прикладного программирования нового поколения

Сценарная парадигма [22]. Сценарная парадигма предполагает разбиение

задачи на отдельные части, каждая из которых решается специализированными

программными средствами, сценарий выступает в роли «диспетчера», ответствен-

ного за организацию их взаимодействия. Концепция сценарного программирования

возникла как естественное развитие языка LISP. Первые сценарные (скриптовые)

языки служили средством управления командной оболочкой операционных систем

- командный файл на языке операционной системы содержал сценарий управления

заданной последовательностью действий по организации взаимодействия элемен-

тов системы.

В настоящее время популярность сценарных языков связана с развитием

Internet-технологий. Скриптовые языки используются для создания динамических,

интерактивных web-станиц, содержание которых модифицируется в зависимости

от действий пользователя и состояния остальных страниц и данных. Сценарный

язык в малой степени ориентируется на создание конечного продукта с нуля и в

большей степени – на использование тех мощностей, которыми обладает операци-

онная система, графическая среда, прикладная сервисная машина и прочие подоб-

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

Сценарные языки для web-разработки в основном созданы в 90-е годы про-

шлого века и включают в себя элементы различных парадигм программирования.

Среди наиболее мощных и популярных скриптовых систем - Perl, Pyton, PHP, ASP.

Компонентно-ориентированное программирование.

Компонентная разра-

ботка (CBSE, от Component based software engineering или CBD, от Component-

based development) – направление в программной инженерии, в основе которого

лежит индустриальный подход к разработке программных систем - «не с нуля», а

путем быстрой сборки из готовых программных компонентов [30-32].

Главная задача CBSE – основываясь на знании свойств отдельных интегри-

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

обобщает идеи объектно-ориентированной парадигмы, повторного использования

[33], абстрактных архитектур, формальных спецификаций и т.п. и базируется на

концепциях компонента (component), интерфейса (interface), контракта (contract),

компонентной модели (component model), компонентного каркаса (component

framework), композиции (composition) и сертификации (certification).

Схематическое описание модели компонентной системы представлено на ри-

сунке 2.7 и кратко прокомментировано далее [34].

Компонент (1) – это программная реализация (исполнимый код) функций

объекта, предназначенная для выполнения (работы) на физическом или логическом

устройстве. Наряду с функциональностью компонент реализует один или более

интерфейсов (2) в соответствии с определенными обязательствами, описанными в

контракте (3). Контрактные обязательства гарантируют, что независимо разрабо-

танные компоненты руководствуются определенными правилами поведения, могут

взаимодействовать друг с другом предсказуемым образом и разворачиваться в

стандартных средах (4) (на этапе построения системы или на этапе ее исполне-

ния (работы)).

100 Глава 2

Data

Компонентный каркас

Компонентная

модель

Интерфейс,

специфичный

для компонентного

типа

Реализует интерфейс и

специфицирует контракт

Независимое

развертывание

Реализация

компонента

Компонентные

типы и контракты

Координационные

сервисы

(транзакции, ....)

Рис. 2.7. Модель компонентной системы

Компонентная система основывается на небольшом количестве разных типов

компонентов (5), каждый из которых играет специализированную роль в системе и

описывается интерфейсом (2). Компонентная модель (6) представляет собой мно-

жество типов компонентов, их интерфейсов и, дополнительно, спецификацию до-

пустимых шаблонов (паттернов) взаимодействия типов компонентов. Компо-

нентный каркас (7) обеспечивает множество сервисов (8) периода времени выпол-

нения для поддержки функционирования компонентной модели. Во многих отно-

шениях компонентные каркасы уподобляются специализированным операционным

системам, хотя они оперируют на гораздо более высоких уровнях абстракции и

имеют гораздо более ограниченный диапазон механизмов координации взаимодей-

ствия компонентов.

Компонентный подход дает следующие преимущества при разработке ПС:

- независимые расширения ПС благодаря тому, что элементом (единицей)

расширения является компонент, а компонентная модель и каркас гарантируют, что

расширения не станут причиной непредсказуемого взаимодействия. Независимая

разработка и развертывание расширений;

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

предписывают стандарты, которым должны удовлетворять компоненты для незави-

симой разработки и развертывания в стандартной среде;

- экономия времени выхода на рынок благодаря тому, что ключевые архитек-

турные решения могут быть «встроены» в компонентную модель и каркас;

- предсказуемость обеспечиваемого качества ПС благодаря тому, что ком-

понентные модели и каркасы могут проектироваться с учетом приоритетных атри-

бутов качества для определенной области применения. Компонентные модели оп-

Глава 2 101

ределяют правила проектирования, которые обязательны для всех компонентов,

развертываемых в компонентной системе. По сути, различные «глобальные» свой-

ства системы (например, масштабируемость, безопасность и т.п.) встраиваются не-

посредственно в компонентную модель. Если компонентная модель налагает огра-

ничения на проектируемые компоненты, то компонентный каркас реализует эти

ограничения наряду с предоставлением необходимых сервисов.

Наиболее важный аспект CBSE - предсказуемость композиции взаимодейст-

вующих компонентов и каркасов. Возможны три основных вида композиций в ПС:

– «компонент-компонент» (взаимодействие по контрактам прикладного уров-

ня, определяемое во время разработки (раннее связывание) или, что предпочти-

тельнее, во время выполнения (позднее связывание)),

– «каркас-компонент» (взаимодействие между компонентом и другими ком-

понентами каркаса по контрактам системного уровня с обеспечением управления

ресурсами),

– «каркас-каркас» (взаимодействия между компонентами, разворачиваемыми

в гетерогенных средах (каркасах) по контрактам интероперабельного

(interoperation) уровня).

Компонент выступает в двух ипостасях – как реализация (разрабатываемая,

развертываемая и интегрируемая в систему) и как архитектурная абстракция (от-

ражающая правила проектирования, предлагаемые стандартной моделью для всех

компонентов).

Компоненты могут изменяться и пополняться новыми функциональными

возможностями и интерфейсами. Один компонент может содержать реализацию

нескольких разных интерфейсов, а один интерфейс, в свою очередь, может быть

реализован в разных компонентах. Замена одного компонента другим не должна

приводить к перекомпиляции или перенастройке связей в ПС.

Компоненты конструируются в виде некоторой программной абстракции,

включающей:

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

применения (ОС, платформа и т.п.), возможностей повторного использования и др.;

внешнюю часть – интерфейсы, определяющие взаимодействие компонента с

внешней средой и с платформами, на которых он будет работать, и обеспечиваю-

щие следующие общие характеристики компонента:

– интероперабельность – способность взаимодействовать с компонентами

других сред;

– переносность (мобильность) – способность работать на разных платфор-

мах компьютеров;

– интегрируемость – способность к объединению с другими компонентами

в сложные ПС;

– не функциональные характеристики - безопасность, надежность и защи-

ту компонента и данных;

внутреннюю часть – фрагмент программного кода или абстрактную структу-

ру - проект компонента, его спецификацию и исходный код – которые реализуют

интерфейсы компонента, его функциональность и схемы развертывания.

Спецификация интерфейса может выполняться средствами API (Application

Programming Interface) определенного языка программирования (с отражением

только функциональных возможностей компонента) или на языке спецификации

102 Глава 2

интерфейса (нейтральном к языку программирования) - Interface Definition Lan-

guage (IDL) (с отражением также и экстра-функциональных возможностей – спе-

цификаций поведения (пред- и пост- условий выполнения операций и их результа-

та), спецификаций синхронизации функций во времени, характеристик качества

предоставляемого сервиса - точность, быстрота отклика и др.).

Современные языки программирования, например, Java, имеют расширения,

специально предназначенные для спецификации поведения: iContract, JML (Java

Modeling Language), Jass (Java with assertions), Biscotti и JINSLA (Java INterface

Specification LAnguage). Могут использоваться также методы (языки) VDM

(VDM++), Z (OOZE, Object-Z). Все они обеспечивают описание последовательно-

сти выполнения операций безотносительно ко времени. Для описания синхрониза-

ции операций в распределенных и параллельных системах могут использоваться,

например, Object Calculus, CSP (Communicating Sequential Processes), Piccola, а для

спецификации не функциональных атрибутов - NoFun. Специфицировать можно

также сложность компонента, используя для этого функции библиотек

Apple/SANE™.

В CBSE осуществлен переход от концепции специфицирования собственно

компонентов к концепции специфицирования схем (шаблонов) их взаимодействия

путем определения контрактов – с одной стороны, обязательств компонента (шаб-

лонов взаимодействия, обеспечиваемых компонентом), а с другой стороны, правил

взаимодействия (абстрактных шаблонов взаимодействия в соответствии с ролью в

системе, которая возлагается на компонент).

Таким образом, компонентные системы основываются на четко определен-

ных стандартах и соглашениях для разработчиков компонентов (определяемых

компонентной моделью) и поддерживающей их инфраструктуре (компонентном

каркасе), которая реализует сервисы для модели или приводит ее в действие, оче-

видно упрощая развертывание отдельных компонентов и приложений.

Компонентная модель предлагает:

- стандарты по типам компонентов (например, проекты, формы, beans-

компоненты, COBRA-компоненты, RMI-компоненты, стандартные классы-

оболочки, базы данных, JSP-компоненты, сервлеты, XML-документы, DTD-

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

- стандарты схем взаимодействия (методы локализации, протоколы комму-

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

транзакциями и др.),

- соглашения о связывании компонентов с ресурсами (сервисами, предостав-

ляемыми каркасом или другим компонентом, развернутым в данном каркасе). Мо-

дель описывает, какие ресурсы доступны компонентам, и как, и когда компоненты

связываются с этими ресурсами. Каркас, в свою очередь, рассматривает компонен-

ты как ресурсы, подлежащие управлению.

Компонентный каркас (подобно операционной системе, объекты действия

которой - компоненты) управляет ресурсами, разделяемыми компонентами, и пре-

доставляет механизмы для коммуникации (организации взаимодействия) компо-

нентов. Каркас необязательно существует отдельно от компонентов во время рабо-

ты системы, его реализация может быть объединена с реализацией компонента, хо-

тя предпочтительнее первое, как, например, каркас для поддержки компонентной

модели EJB (Enterprise JavaBeans™). Примером визуализации композиции компо-

Глава 2 103

нентов может служить каркас VBXs (интерпретатор Microsoft Visual Basic) совме-

стно с COM-разверткой и коммуникационными сервисами, предоставляемыми ис-

ходной ОС.

Продолжительность успеха компонентной инженерии будет обусловлена

доступностью высококачественных программных компонентов и доверием потре-

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

жет быть обеспечено путем сертификации компонентов. Сертификации подлежат

отдельные компоненты, каркасы и система, ими образованная. Однако, существует

зависимость свойств системы от свойств сертифицируемых компонентов и, чем

больше эта зависимость, тем более значимыми будут результаты сертификации

компонентов. В пределе, при 100% уверенности (доверии) к каузальной связи, во-

обще отпадет необходимость сертифицировать систему. Она будет «правильной»

по определению (по крайней мере, в контексте определенных свойств, по которым

установлена зависимость). В отсутствии 100% уверенности проблема сертифика-

ции системы переходит в плоскость предсказаний и обоснований композиций ком-

понентов в условиях существующей неопределенности.

Таким образом, суть и цель компонентной программной инженерии заключа-

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

компоненты и каркасы обладают сертифицированными свойствами, обеспечи-

вающими базис для предсказания свойств системы в целом.

С точки зрения программирования парадигма компонентного программиро-

вания – это попытка решить те проблемы, которые возникают при использовании

объектно-ориентированной парадигмы. Это, например, организация повторного

использования путем распространения библиотек классов (исходного кода) или

динамически компонуемых библиотек (dll-библиотек), проблема разработки рас-

пределенных приложений и др.

Основная идея новой парадигмы - распространение классов в бинарном виде

(т.е. не в виде исходного кода) и предоставление доступа к методам класса через

строго определенные интерфейсы, что позволяет снять проблему несовместимости

компиляторов и обеспечивает смену версий классов без перекомпиляции исполь-

зующих их приложений [35].

Наиболее известные технологии, реализующие парадигму компонентного

программирования, - COM (DCOM, COM+), CORBA, .Net.

Сервисно-ориентированное программирование. Сервисно-ориентированное

программирование (или архитектура ПО) (service-oriented architecture) — развитие

компонентного подхода к разработке программного обеспечения, основанное на

использовании программ-сервисов со стандартизированными интерфейсами.

Компоненты ПС могут быть распределены по разным узлам сети, и предлагаться

как независимые, слабо связанные, заменяемые сервисы-приложения. Интерфейс

компонентов ПС обеспечивает инкапсуляцию деталей реализации каждого конкрет-

ного компонента от остальных. Таким образом, сервисно-ориентированная архи-

тектура предоставляет гибкий способ комбинирования и повторного использования

компонентов для построения сложных распределенных программных систем, в ча-

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

Программные системы, разработанные в соответствии с этой парадигмой,

часто реализуются как набор Web-сервисов, интегрированных с помощью извест-

ных стандартных протоколов (SOAP, WSDL и т.п.).