Глава 18. Конструирование систем из коробочных компонентов

Конструирование систем из коробочных компонентов

(в соавторстве с Робертом С. Сикордом и Мэтью Бассом) ^[10]

На блюде все это смотрится так красиво — чьи-то пальчики основательно потрудились!

Джулия Чайлд о повой французской кухне

Мы постоянно делаем упор на связь между требованиями по качеству и архитек­турой. Утверждение это основывается на допущении о том, что контроль над проектным решением системы подразумевает контроль над реализуемыми ею атрибутами качества. Чем дальше, тем больше оно опровергается реальной прак­тикой. Готовые компоненты для конструирования систем со временем получают широкое распространение — связано это с экономическими соображениями, а так­же с тем, что во многих технических областях для разработки приложений требу­ются крайне специализированные знания. Компоненты, с одной стороны, вносят в процесс проектирования существенные коррективы, но с другой — ограничива­ют архитектуру. Отбираемые для реализации определенного функционального набора, компоненты выражают те или иные архитектурные допущения (а значит, и допущения по качеству). Задача архитектора состоит в том, чтобы обеспечить корректность выбора этих допущений и их совместимость.

Начиная с 1960-х годов принятие многих проектных решений в значительной степени зависит от конкретной операционной системы. Системы управления ба­зами данных сформировались как фактор влияния в начале 1970-x. Повсемест­ное распространение компьютеров привело к повышению возможностей исполь­зования для реализации системных задач компонентов, разработанных третьей стороной. Само по себе наличие компонентов не является принудительным стимулом к их использованию (и этом контексте см. врезку «Quack.com»), что, од­нако, не сокращает потребность в изучении механизмов их внедрения в систему Процесс отбора коробочных компонентов для системы предполагает поиск сборок (assemblies) совместимых компонентов, формулирование механизма реа­лизации с их помощью атрибутов качества и принятие решений относительно возможности их интеграции в конструируемую систему.

QUACK.COM

Истоки

Компания Quack.com основана в конце 1998 года двумя бывшими сотрудниками Инсти­тута программной инженерии (Джероми Карье (Jeromy Carriere) и Стивом Вудсом (Steve Woods)), а также профессором Гавайского университета Алексом Квилиси (Alex Quilici). Вооружившись идеей обеспечить доступ к коммерческой информации и данным иного характера no телефону, они сконструировали демонстрационную версию программы и к концу лета 1999-го добились финансирования со стороны ряда «благодетелей» и вен­чурных компаний. Осознавая важность голосовой архитектуры, они выстроили «реаль­ную» систему в виде голосового портала поверх комплекта инструментов и платформы публикации голосовых приложений. В результате им удалось оперативно сконструировать и организовать сопровождение широкого ряда приложений. В принципе, спроектирован­ная ими платформа имела все шансы на доминирование в зарождающейся индустрии. Через десять месяцев после начала финансирования они выпустили предварительную версию потребительского голосового веб-портапа. Он предоставлял услуги доступа к ин­формации о погоде, кинофильмах, курсах акций и прочим данным потелефону, 31 авгус­та 2000-го компания вошла в состав America Online. Вскоре — 25 октября 2000 года — AOL выпустила приложение AOLbyPhone, сконструированное группой разработчиков Quack на основе их же платформы и инструментального набора.

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

Первый портал Quack, внесший весомый вклад в последующий успех проекта, оказался вполне полезным сам по себе, однако широкого внимания пользователей так и не получил. После приобретения проекта корпорацией AOL коммерческие приоритеты резко поменялись. Располагая базой из 34 000 000 подписчиков, AOL вывела на первый план такие коммерче­ские факторы, как готовность и производительность. Портал Quack.com предстояло подго­товить к более интенсивному режиму использования и обеспечить соответствие более жест­ким требованиям по готовности.

Для подгонки проекта под новые требования было решено переписать компоненты. Верти­кальное масштабирование и повышение готовности в рамках гибкой архитектуры не представ­ляло особых проблем; в то же время предсказать реакцию компонентов на предполагаемые изменения оказалось категорически невозможно. Получить контроль над производительно­стью и готовностью системы в целом можно было лишь путем их переписывания (в порядке убывания критичности).

Многие другие системы прошли аналогичный этап. Недавно мы посетили небольшую на­чинающую компанию, занятую построением новой линейки программных продуктов. Пони­мая, что второго шанса произвести первое впечатление не будет, ее сотрудники поставили надежность и масштабируемость на вершину списка архитектурных задач. По словам их ар­хитектора, «если функция не слишком важна, мы ограничиваемся коробочным компонентом. Если в отношении того или иного аспекта системы существует официальный или фактиче­ский стандарт, подходящий коробочный компонент можно выбрать — скорее всего, этот стан­дарт соблюдается разными производителями. Если же у нас есть какие-то сомнения и мы не можем найти очевидных решений, значит, нужно конструировать компонент собственными силами». Прежде чем перейти к работе над новым проектом, этот архитектор участвовал в создании крупной поисковой системы и контент-провайдера. За четыре года число суточных посещений увеличилось с 45 000 до 45 000 000. Работая с системой многомиллионной посе­щаемости, он очень быстро научился действовать так, чтобы не просыпаться по ночам в свя­зи с очередной проблемой, угрожающей коммерческой деятельности.

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

- LJB и PCC

В настоящей главе мы рассмотрим упрощенный процесс отбора компонентов исходя из практических соображений. Сначала формулируются гипотезы о том, как должны «работать» выбранные компоненты. Затем для проверки этих гипо­тез строятся простые макеты. Наконец, после оценки функционирования маке­тов, на случай опровержения гипотез составляется запасной план. Основной прин­цип этой методики состоит в том, что отбирать единичные компоненты не имеет смысла. Отбирать и тестировать нужно сборки совместно функционирующих компонентов.

Кроме того, ниже мы опишем приложение данного процесса к недавно со­зданной системе.

18.1. Воздействие компонентов на архитектуру

Предположим, вы разрабатываете программное обеспечение системы управле­ния химическим предприятием. Специальные дисплеи на этом предприятии ин­формируют операторов о состоянии проводимых реакций. Одна из основных задач разрабатываемого программного обеспечения заключается в выводе информации на эти дисплеи. Вам известно, что среди продуктов, предлагаемых одним из про­изводителей, числятся элементы управления пользовательским интерфейсом, способные решить эту задачу. Поскольку купить проще, чем сконструировать, вы собираетесь приобрести эти элементы управления, которые, кстати, написаны в единственной версии — на Visual Basic.

Какое влияние на архитектуру окажет принятое решение? Либо на Visual Basic с присущей ему ориентированностью на обратные вызовы придется написать всю систему, либо операторскую часть нужно каким-то образом изолировать от всех остальных частей системы. Это основополагающее структурное решение, необхо­димость в принятии которого обусловливается отбором единичного компонента для конструирования отдельной части системы.

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

Все компоненты, за исключением самых простых, основываются на допущении об использовании того или иного архитектурного образца, нарушать которое довольно сложно. К примеру, HTTP-сервер предполагает применение клиент-сер­верного архитектурного образца с определенными интерфейсами и механизмами интегрирования серверной функциональности. Если проектируемая архитектура не соответствует допущениям, заложенным в компоненте HTTP-сервера, задача интеграции очень сильно усложняется.

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

18.2. Архитектурное несоответствие

Далеко не все компоненты способны к взаимодействию — даже если это коммер­ческие продукты, совместимость которых утверждается производителем. Зача­стую они «почти совместимы», причем «почти» в данном случае означает факти­ческую несовместимость. Бывают и более хитрые ситуации — компоненты внешне демонстрируют способность к совместной работе (собранный код компилируется и даже исполняется), и тем не менее из-за того что реальный механизм взаимо­действия компонентов не отвечает ожиданиям, реакции оказываются некоррект­ными. Подобного рода ошибки могут быть едва заметны — особенно в системах реального времени и в параллельных системах, в которых компоненты основыва­ются на безобидных на первый взгляд допущениях о времени и относительной последовательности операций.

Короче говоря, компонент, если он не разработан специально для вашей си­стемы, может не соответствовать всем вашим требованиям, более того, он может отказаться работать совместно с другими компонентами. Хуже всего то, что для проверки применимости компонента его, как правило, нужно сначала приобрес­ти. Дело в том, что предоставляемой информации об атрибутах качества интер­фейсов компонентов обычно оказывается недостаточно. Насколько безопасен ваш компилятор? Насколько надежна ваша почтовая система? Насколько точна мате­матическая библиотека, к которой обращаются ваши приложения? И что делать, если окажется, что эти элементы «недостаточно» безопасны/надежны/точны?

Подобного рода препятствия к успешной интеграции компонентных систем Гарлан (Garlan), Аллен (Allen) и Окерблум (Ockerbloom) назвали архитектурным несоответствием (architectural mismatch). Эту проблему они рассматрива­ют как несогласованность допущений, принимаемых в раздельно разработанных компонентах. Во многих случаях эта несогласованность обнаруживает себя в ар­хитектуре — например, если два компонента не могут договориться о том, кто из них кого запускает. Архитектурные несоответствия чаще всего обнаруживаются и период интеграции — система элементарно отказывается компилироваться, ком­поноваться или исполняться.

Архитектурное несоответствие есть частный случай интерфейсного несоот­ветствия (interface mismatch). В данном случае имеется в виду определение ин­терфейса по Парнасу (Parnas) — допущения компонентов друг о друге. Это опре­деление шире стандартного понятия интерфейса, которое, к сожалению, прочно прижилось в современной практике и соответствует интерфейсу прикладного программирования компонента (пример тому — спецификация интерфейса). Интерфейс прикладного программирования содержит имена программ и их па­раметров, а также (иногда) доносит отдельные сведения об их поведении; тем не менее, это лишь малая часть информации, необходимой для обеспечения коррект­ного использования компонента. В полную спецификацию интерфейса должны входить сведения о побочных эффектах, потреблении глобальных ресурсов, тре­бованиям по координации и пр. Подобно архитектурному несоответствию, ин­терфейсное несоответствие обнаруживается в период интеграции и может высту­пать причиной возникновения упомянутых выше хитроумных ошибок в период исполнения.

Допущения можно разделить на два подвида. Допущения о предоставляемых услугах (provides assumptions) характеризуют службы, которые компонент предо­ставляет пользователям или клиентам. Допущения о требованиях (requires assump­tions) подробно описывают службы и ресурсы, необходимые для корректного функционирования компонента. Несоответствие между двумя компонентами происходит в случае, если принимаемые ими допущения двух обозначенных раз­новидностей не совпадают.

Как бороться с интерфейсным несоответствием? Помимо изменения требова­ний — так, чтобы вчерашние дефекты стали сегодняшними характеристиками (да, иногда можно сделать и так), — есть еще три способа.

♦ Специфицирование и проверка компонентов системы позволяет предотвра­щать несоответствия.

♦ Обнаруживать те несоответствия, которые не удалось предотвратить, по­могает тщательная квалификация компонентов.

♦ Исправлять выявленные несоответствия следует методом адаптации ком­понентов.

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

Проблема исправления несоответствий (или «исправления компонентов/интер­фейсов») до сих пор не удостоена систематического анализа. Термины наподобие «связки компонентов» отражают характер интеграционного кода и соответствуют статусу «второй сорт», присваиваемому их разработке. Исправление интерфейс­ных несоответствий зачастую трактуется как задача хакеров и (иногда) неопыт­ных программистов, у которых эстетическое ощущение не опустошено тысячами «поделок», из которых состоит процесс интегрировании коробочных компонен­тов. По нашему мнению, это тот самый случай, когда надежность цепочки равна надежности ее слабого звена. Иначе говоря, от качества исправления компонента напрямую зависит успех (или неспособность) реализации общесистемных задач no качеству наподобие готовности и модифицируемости.

Первым шагом на пути систематизации процесса исправления интерфейса мы считаем классификацию основных методик, которыми эта задача решается, и их характеристик. Есть очевидный метод исправления. Заключается он в том, чтобы изменить код проблемного компонента. Это решение далеко не всегда осуще­ствимо — коммерческие продукты довольно редко сопровождаются исходным кодом. Если же речь идет о старом компоненте, то найти его исходный код или человека, который способен в нем разобраться, обычно оказывается крайне слож­но. Даже если такая возможность есть, во многих случаях корректировать код компонента нежелательно. Компоненты по определению используются во мно­жестве систем. Таким образом, если изменения, направленные на обеспечение работоспособности компонента в новой системе, приведут к тому, что он переста­нет работать в старых системах, сопровождать придется уже не одну, а несколько его версий.

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

Оболочки

Термин «оболочка» (wrapper) предполагает инкапсуляцию, посредством которой компонент упаковывается в альтернативную абстракцию. Иначе говоря, клиент обращается к службам «завернутого» компонента исключительно через предо­ставляемый оболочкой альтернативный интерфейс. Можно сказать, что оборачи­вание — это создание альтернативного интерфейса компонента. Трансляция ин­терфейса подразумевает проведение трех операций:

♦ трансляцию элемента интерфейса компонента в альтернативный элемент;

♦ сокрытие элемента интерфейса компонента;

♦ недопущение модификации элемента базового интерфейса компонента.

Предположим, что в нашем распоряжении унаследованный компонент, предо­ставляющий программный доступ к службам визуализации графики. При этом программная служба существует в виде библиотек Fortran, а визуализация гра­фики осуществляется в терминах специальных графических примитивов. Задача в том, чтобы, во-первых, сделать компоненты доступными клиентам через CORBA, а во-вторых, заменить специальные графические примитивы графическими эле­ментами X Window System.

Для специфицирования нового интерфейса, обеспечивающего доступность служб компонентов клиентам CORBA, имеет смысл обратиться к языку описа­ния интерфейсов (interface description language, IDL) — это решение удачнее свя­зывания с библиотеками Fortran. В качестве кода, исправляющего допущения интерфейсов о предоставляемых службах, выступает «скелетный код» на С++, который генерируется компилятором IDL автоматически. Кроме того, в состав исправительного кода входит рукописный код, привязывающий скелет к функ­циональности компонента.

Что касается оборачивания допущений о требованиях компонентною интер­фейса, необходимого для окончательного перехода от специальных графических элементов к системе X Window, то здесь есть несколько вариантов. Одно из ре­шений заключается в том, чтобы написать уровень для библиотеки трансляции, чей API соответствует API специальных графических примитивов; реализация этой библиотеки будет проводить трансляцию вызовов специальных графиче­ских элементов в вызовы X Window.

Мосты

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

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

Предположим, что в нашем распоряжении два унаследованных компонента. Один создает выходные макеты проектных документов на PostScript, а другой отображает документы в формате PDF (Portable Document Format). Задача — интегрировать эти компоненты, чтобы в отношении любого проектного докумен­та можно было запустить компонент отображения.

Наиболее очевидным решением исправления интерфейса для данного сцена­рия представляется простой мост, транслирующий PostScript в PDF. Писать его можно независимо от конкретных характеристик двух наших гипотетических компонентов — к примеру, имеет смысл создать механизм, извлекающий данные из одного компонента и наполняющий ими другой. В этом контексте на ум сразу приходят фильтры UNIX, однако это не единственный механизм, способный вы­полнить поставленную задачу.

Для исполнения такого моста можно написать сценарий. Он должен будет разбираться со спецификой интерфейсов интегрируемых компонентов. Следо­вательно, поскольку внешний агент/оболочка (shell) имеет дело с интерфейсами на обоих концах отношения интеграции, он не подпадает под наше определение оболочки (wrapper). С другой стороны, можно сделать так, чтобы каждый из двух компонентов мог самостоятельно запускать фильтр. В этом случае механизм ис­правления будет представлять собой гибрид оболочки и фильтра — в оболочке будет содержаться исправительный код, необходимый для определения потреб­ности в запуске моста и для инициирования самого запуска.

Посредники

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

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

Возьмем, к примеру, сценарий интеллектуального слияния данных. Рассмот­рим датчик, генерирующий высокоточные данные в больших объемах. В период исполнения действуют разные потребители информации с разными рабочими допущениями о точности данных. Одному потребителю, который, скажем, допус­кает низкую точность данных, нужно «выдрать» из потока данных определенную информацию. Другому потребителю с аналогичными требованиями по точности, но иными характеристиками по части пропускной способности, требуется вре­менная буферизация данных. В каждом из этих случаев согласование датчика и его потребителей выполняет посредник.

Рассмотрим другой сценарий — сборка последовательности мостов в период прогона, направленная на интеграцию компонентов, при условии, что их требо­вания по интеграции становятся известны именно в этот период. К примеру, один компонент производит данные в формате D⁰, а другой потребляет данные в фор­мате D². Прямого моста D°->D² может и не быть, зато есть мосты D°->D' и D'->D², которые можно сцепить. Роль посредника, таким образом, будет заключаться в том, чтобы собрать эти мосты и тем самым провести преобразование D°->D². Этот сценарий одновременно распространяется на традиционное понятие настольной интеграции и на более экзотичные адаптивные системы периода прогона.

Методики обнаружения интерфейсных несоответствий

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

Термин квалификация компонентов (component qualification) обозначает про­цесс, в ходе которого проверяется соответствие коммерческого компонента ряду критериев «годности к использованию». Среди неотъемлемых процессов квали­фикации компонентов — макетная интеграция компонентов-кандидатов. На этом этапе интеграции выявляются малозаметные, трудно поддающиеся обнаружению разновидности интерфейсных несоответствий — например, состязания за ресур­сы. Фактически, потребность в проведении этого этапа обусловливается недоста­точностью наших познаний в области интерфейсов компонентов.

Проверка эта исходит из наблюдения, согласно которому для предоставления каждой службы компонента необходимо удовлетворить ряд принимаемых им допущений о требованиях. Ведь служба — это не более чем удобный способ опи­сания механизма пакетирования функциональности компонента в расчете на ее применение клиентами. Таким образом, квалификация предполагает:

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

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

Перейдем к конкретике и рассмотрим квалификацию компонента, предостав­ляющего многопоточным приложениям службы управления примитивными дан­ными. В частности, этот компонент позволяет записывать значения данных в указанное местоположение (которое может задаваться с помощью ключа). В це­лях предоставления многопоточной службы хранения компоненту требуется от операционной системы ряд ресурсов — к примеру, файловая система и примити­вы блокировки. Перечень принимаемых компонентом допущений о требованиях может быть (а может и не быть) составлен производителем компонента; если таковой отсутствует, значит, выявлением этих требований приходится занимать­ся оценщику компонента. В любом случае, конкретное отображение позволит сделать выводы о воздействии обновления операционной системы на данное от­ношение интеграции. Иными словами, меняется ли в ходе обновления операци­онной системы семантика операций fwrite и fLock?

В упомянутый перечень можно внести дополнительные допущения — к при­меру, возможно такое допущение о представляемых услугах, согласно которому у устройства хранения должен быть интерфейс CORBA. В зависимости от конк­ретной реализации брокера объектных запросов это допущение предполагает или не предполагает появления нового допущения о предоставляемых услугах, со­гласно которому на базовой машине, размещающей данное устройство хранения, должен исполняться процесс брокера объектных запросов. На основе перечня допущений иногда выявляются значительно более интригующие зависимости. К примеру, тот же самый гипотетический компонент может устанавливать задан­ное (но переменное) число клиентов, работающих с одним внешним процессом диспетчера данных, — соответственно, для всех клиентов сверх заданного коли­чества нужно выделять дополнительные процессы. Подобные допущения позво­ляют точно определиться с тем, соответствует ли компонент всем ограничениям по ресурсам системы.

Методики предотвращения интерфейсных несоответствий

Согласно одному из методов предотвращения интерфейсных несоответствий, с са­мых ранних стадий проектирования следует систематически устанавливать как

можно больше допущений об интерфейсе компонента. Возможно ли специфици­ровать все допущения, принимаемые компонентом о своем окружении, а также те нз них, которые ему дозволено принимать используемыми компонентами? Естественно, нет. Имеет ли смысл выделить важное подмножество допущений и есть ли у нас свидетельства, подтверждающие эффективность такого подхода? Да, есть. В проектном решении программного обеспечения A-7E, обзор которого содержится в главе 3, система подразделяется на иерархическое дерево модулей. На его высшем уровне содержится три модуля, а на листьях их 120. Для каждого листового модуля составлена спецификация интерфейса, в которой обозначают­ся программа доступа (в объектном проектировании эти программы называются методами), требуемые и возвращаемые параметры, видимые следствия вызова программы, параметры генерации системы, предусматривающие регулировку модуля в период компиляции, а также ряд допущений (примерно по дюжине на каждый модуль).

В допущениях выражались утверждения относительно достаточности (suffi­ciency) предоставляемых каждым модулем служб, а также возможности реализа­ции (implementability) каждой службы в категориях требуемых модулям ресур­сов. Среди конкретных тематических областей числились потребление совместно используемых ресурсов, следствия прохождения через средства модуля множе­ства потоков управления, а также производительность. Эти допущения должны были оставаться неизменными на протяжении всего жизненного цикла системы, в которой модифицируемость позиционировалось как основная проектная зада­ча. Обращаясь к допущениям, проектировщики модулей проверяли, в полной ли мере им удалось инкапсулировать в своих модулях области изменений. Специа­листы в предметной и прикладной областях с помощью допущений проводили оценочные мероприятия, а пользователи модулей удостоверяли их пригодность. По убеждению участников проекта A-7, внимательное отношение к интерфейсам модулей, по сути, исключает необходимость проведения этапа интеграции (в рам­ках жизненного цикла программы). Почему? Средством предотвращения архи­тектурных несоответствий они избрали тщательное специфицирование — в част­ности, проверку достоверности явных перечней допущений силами специалистов в предметной и прикладной областях.

Определение интерфейса как набора допущений, выводящее его за рамки ин­терфейса прикладного программирования, расширяет понимание процесса спе­цифицирования интерфейсов компонентов, взаимодействующих друг с другом в различных контекстах. Приватные интерфейсы (private interfaces) раскрывают только те принимаемые базовым интерфейсом компонента допущения о предо­ставляемых услугах и требованиях, которые являются значимыми в контексте требований по интеграции в конкретной системе или даже в контексте ее отдель­ных компонентов. Таким образом, информация о ненужных средствах, присут­ствие которых приводит к излишнему усложнению системы, скрывается.

Мы перечислили преимущества нескольких различных интерфейсов для од­ного компонента в противоположность единому многоаспектному базовому ин­терфейсу. Ужесточение контроля над межкомпонентными зависимостями увели­чивает возможности манипулирования отдельными видами развития систем — в частности, предсказуемость воздействия модернизации коммерческого компонента на новую версию. Оболочки как стратегия исправления ориентированы на обес­печение конфиденциальности. Архитектурные образцы, со своей стороны, пре­дусматривают стандартные формы удовлетворения допущений интерфейсов о пре­доставляемых услугах и требованиях — в системе на основе архитектурного образца, определяющего компактный набор типов компонентов, количество про­изводных базового интерфейса значительно сокращается.

Параметризованным (parameterized) называется интерфейс, предусматрива­ющий возможность изменения допущений о предоставляемых службах и требо­ваниях перед вызовом службы соответствующего компонента; эта возможность обеспечивается путем изменения значения переменной. В языках программиро­вания давно сформировались методики параметризации с развитой семантикой, позволяющие регулировать интерфейс компонента с момента его проектирова­ния и кодирования до момента вызова его служб (примеры таких методик — настраиваемость в Ada и полиморфизм в ML). Возможность настройки в ком­мерческих продуктах часто обеспечивается за счет параметризации (например, файлов ресурсов и переменных среды). Параметризованные интерфейсы преду­сматривают создание адаптационного кода, который по отношению к компонен­ту является одновременно внешним (в том, что касается настройки значений параметров) и внутренним (по части приспособления к значениям параметров).

Подобно посреднику, который определяется как мост с логикой планирова­ния, согласованный интерфейс (negotiated interface) представляет собой парамет­ризованный интерфейс с логикой самоисправления. Параметризация такого ин­терфейса производится либо его же средствами, либо внешним агентом. Можно даже утверждать, что согласованные интерфейсы характерны для программных средств с автоматическим конфигурированием — согласование при этом прохо­дит в форме одностороннего диалога по принципу «решайте сами», проводяще­гося между программой конструирования компонентов и базовой платформой. Есть и другой вариант — некоторые продукты (в частности, модемы) в период прогона (вместо периода установки) определяют взаимоприемлемые параметры связи путем регулярного запуска специальных протоколов.

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