Глава 11 8 страница

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

Веб-серверы ради производительности

Наконец, запрос HTTP или HTTPS прибывает иа веб-сервер. Старые веб-серве­ры (один из таких изображается на рис. 13.5) в основном были однопоточными. Современные версии веб-серверов отличаются многопоточностью и применени­ем пулов потоков, распределяемых для обработки входящих запросов. Распола­гая пулом с потоками, готовыми для обслуживания новых входящих запросов, многопоточный сервер снижает вероятность образования узких мест (а следова­тельно, и задержек) при обработке многочисленных «долгоиграющих» запросов HTTP или HTTPS (к таковым относятся операции проверки достоверности дан­ных кредитных карт). Таким образом реализуется тактика «введение параллелизма».

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

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

В главе 16 мы разберем систему корпоративных JavaBeans (Enterprise Java- Beans) — современную методику реализации веб-серверов.

Серверы приложений ради модифицируемости, производительности и масштабируемости

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

Простые серверы приложений, как правило, состоят из интегрированной сре­ды разработки (integrated development environment, IDE) и сервера исполнения. Среды IDE поддерживают программные модели наподобие СОМ (а в последнее время —.NET), CORBA или J2EE (последняя рассматривается в главе 16). По­мимо этого, многие серверы приложений предусматривают наборы общеупотре­бительных служб для оперативного создания бизнес-приложений и приложений электронной коммерции — в частности, предназначенных для выписывания сче­тов, управления запасами, документооборотом и взаимодействием с заказчика-

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

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

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

13.5. Реализация задач по качеству

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

Таблица 13.3.Реализация задач по качеству в веб-архитектуре систем электронной коммерции Задача Как реализуется Тактики Высокая Выравнивание нагрузки, Введение параллелизма; производительность трансляция сетевых адресов, многоэкземплярная тактика расширение ресурсов; прокси-серверы Высокая готовность Резервные процессоры, сети, базы данных и программы; выравнивание нагрузки Активное резервирование; транзакции; введение параллелизма Масштабируемость Обеспечение горизонтального и вертикального масштабиро­вания; выравнивание нагрузки Общие абстрактные службы; применение предписанных протоколов; введение параллелизма Безопасность Брандмауэры; шифрование открытым/секретным ключами в общедоступных сетях Ограничение доступа; целостность; ограничение внешних воздействий Модифицируемость Разделение функциональности браузера, проектного решения базы данных и бизнес-логики на отдельные звенья Общие абстрактные службы; семантическая связность; посредник; стабильность интерфейса

 

 

13.6. Архитектурно-экономический цикл сегодня

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

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

♦ Помимо W3C, значительное влияние на эволюцию Всемирной паутины оказывает ряд проектов с открытым кодом — в частности, проект Apache.

♦ CERN никоим образом не участвует в развитии WWW.

♦ Языки с поддержкой веб-технологий (в особенности это касается Java) вносят свои коррективы в способы разработки и доставки функционально­сти в этой среде. (Пример конструирования веб-приложений с помощью Enterprise JavaBeans описывается в главе 18.)

♦ Превращение Всемирной паутины в распределенную среду разработки при­вело к появлению ряда новых организаций и продуктов. К примеру, UDDI (Universal Description, Discovery and Integration, универсальная система предметного описания и интеграции) организует распределенные регист­ры веб-служб. Эти службы используются в качества стандартных блоков распределенных веб-приложений.

На рис. 13.8 изображен архитектурно-экономический цикл Всемирной паути­ны в ее современном виде.

В роли заказчиков выступают производители программных серверов и брау­зеров, а также поставщики услуг и контент-провайдеры. Конечные пользовате­ли — это население планеты. Роль архитектора разделена между W3C и другими консорциумами (в частности, UDDI и Apache), с одной стороны, и несколькими влиятельными компаниями (Sun, Microsoft и AOL/Netscape) — с другой. По всем остальным показателям ABC практически не претерпел изменений — за исклю­чением, пожалуй, того, что техническая база теперь включает саму Всемирную паутину, а следовательно, перечень атрибутов качества дополняется требованием о прямой совместимости.

Возвратный цикл ABC мы разобрали в разделе 1.1. Существование системы со­здает для компании-разработчика и ее заказчиков новые коммерческие возмож­ности. В случае со Всемирной паутиной разработавшая ее компания — CERN — решила дистанцироваться от этого продукта и сосредоточиться на исследованиях в области ядерной физики; из-за этого коммерческими возможностями, создан­ными возвратным циклом ABC, воспользовались другие организации.

Рис. 13.8. Современный архитектурно-экономический цикл Всемирной паутины

 

13.7. Заключение

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

О ТОМ, КАК ВСЕМИРНАЯ ПАУТИНА ИЗМЕНИЛА ДЕЛОВОЙ МИР:-------------------------------------------------------------------------------------------

AMAZON.COM

К моменту открытия в 1995 году своего виртуального представительства Amazon.com, про­дававший более 1 миллиона изданий, по своему масштабу был уже на порядок крупнее сред­нестатистических книжных магазинов. От традиционных магазинов он отличался и по многим другим показателям. Причиной столь разительных отличий оказалась электронная ориента­ция Amazon — реализация задач и предложение продуктов через Сеть.

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

Любой клиент Amazon.com может рассчитывать на индивидуальное обслуживание — - в частности, на предложения книг, сходных с теми, которые он купил или просто просмотрел.

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

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

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

На сегодняшний день Amazon.com, обслуживающий клиентов более чем в 220 странах, претендует на статус крупнейшего сетевого магазина в мире. В его активе — пять междуна­родных веб-сайтов и примерно 20 миллионов зарегистрированных покупателей (немногим меньше, чем население Канады!). Процент повторных сделок достигает 70 % — традицион­ные предприятия розничной торговли могут лишь мечтать о таком показателе. На момент написания этих строк Amazon не удалось закрыть год с положительным балансом, но руко­водство магазина рассчитывает получать прибыль начиная с 2003 года.

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

-RК

13.8. Дополнительная литература

Читателям, желающим поподробнее узнать о концепции гипертекста, мы реко­мендуем ознакомиться с работой [Bush 45] и специализированным выпуском САСМ [САСМ 88].

Информации об истории и развитии Всемирной паутины больше всего в са­мой Всемирной паутине. Среди наших источников — [Berners-Lee 96а], [Gray (http://www.mit.edu/people/mkgray/net)] и [Zakon (http://www.zakon.com/robert/internet/timeline)].

Обширная информация о lib WWW содержится в справочной библиотеке W3C, расположенной по адресу http://www.w3.org/pub/WWW/Library.

Добротное исследование по проблемам сетевой безопасности и криптографии, включая все аспекты защиты во Всемирной паутине, содержится в работе [Stal­lings 99]. Вопросы производительности в системах электронной коммерции хо­рошо освещены в издании [Menasce 00].

Архитектурному стилю, характерному для веб-приложений, посвящена рабо­та [Fielding 96]. Сравнение образцов современных веб-серверов приводится в [Hassan 00]; именно оттуда мы заимствовали (и переработали) схему клиент- серверной архитектуры, показанную на рис. 13.5.

Результаты исследования по употреблению веб-серверов, проведенного в мае 2001 года компанией Netcraft, опубликованы по адресу http://www.netcraft.com/survey /.

 

13.9. Дискуссионные вопросы

1. Мы обозначили ряд атрибутов качества, реализация которых в WWW сде­лала возможным ее ошеломляющий успех: способность к взаимодействию, переносимость, удаленный доступ, расширяемость и масштабируемость. Какое из них, по вашему мнению, оказало на развитие Паутины решающее влияние? Если бы одним из этих качеств пришлось пожертвовать, смогла бы она стать настолько же успешной? Какие компромиссные решения в ар­хитектуре приложений на основе libWWW приходится принимать вслед­ствие сочетания названных задач по качеству?

2. Производительности не оказалось в списке первоначальных задач по каче­ству, которые следовало реализовать во Всемирной паутине. Для успешной системы это довольно необычно. Как вы считаете, почему успех ее все-таки настиг? Можно ли из этого сделать какие-то выводы относительно будуще­го развития вычислительной техники?

3. Какие образцы и тактики прослеживаются в элементах архитектуры, пока­занных на рис. 13.4, 13.5 и 13.7?

Часть 4

ОТ ОДНОЙ СИСТЕМЫ К МНОЖЕСТВУ

В четвертой части мы продолжаем разговор об архитектурно-экономическом цикле. На протяжении первой, второй и третьей частей мы плавно перемещались от характеристики архитектора к проверке архитектуры. Четвертая часть, посвя­щенная вопросам конструирования на основе архитектуры множества систем, содержит также примеры линеек системных продуктов. Проблема подвергается анализу с позиций: 1) базовой технологии линейки продуктов; 2) отдельной ком­пании-производителя систем управления огнем для военных кораблей; 3) обще­отраслевой архитектуры; 4) компании, разрабатывающей продукты на основе общеотраслевой архитектуры, и 5) организации, которая при проектировании своих систем прибегает к использованию коммерческих компонентов.

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

В главе 15 приводится первый в этой части конкретный пример. Объектом нашего внимания станет шведская компания CelsiusTech, создавшая линейку си­стем управления огнем для военных судов. Помимо собственно архитектуры мы обсудим то, каким образом в результате ориентации на линейку продуктов пре­терпела изменения организационная структура и культура компании.

Впрочем, CelsiusTech практикует создание архитектуры в расчете на произ­водство нескольких продуктов. Существуют также архитектуры, ориентирован­ные на целые отрасли промышленности. К примеру, корпоративная архитектура Java 2/система корпоративных JavaBeans (Java 2 Enterprise Edition/Enterprise JavaBeans, J2EE/EJB) — архитектурная спецификация для информационных веб­-систем — исполняет роль базовой архитектуры продуктов, разрабатываемых раз­ными компаниями. Архитектурные решения, характерные для J2EE/EJB, и воз­можные в ее контексте компромиссы рассматриваются в главе 16.

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

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

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

 

 

Глава 14

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

(в соавторстве с Линдой Нортроп)

Первым на необходимость повсеместного введения практики многократного использования программных компонентов указал Макилрой. Было это в 1969 году. С тех пор сообщество разработчиков ПО беспрерывно бьется над осуществлением этой задачи. Отсюда зако­номерный вопрос: если преимущества повторно исполь­зуемых программных компонентов настолько ошелом­ляющи, почему они еще не шествуют по компьютерным наукам победным маршем?

Грэди Буч [Booch 94]

14.1. Обзор

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

Речь в настоящей главе пойдет о явном, планируемом повторном использовании программной архитектуры (равно как и других активов) в рамках семейства родственных систем. Разработка нескольких сходных систем на основе одной архитектуры (а также элементов, связанных с этой архитектурой) создает для компании значительные преимущества — конкретнее, снижает стоимость конст­руирования и сокращает время выхода на рынок. Именно этим объясняется при­влекательность линейки программных продуктов (software product line), опреде­ляемой как:

Набор преимущественно программных систем с общим контролируемым множе­ством характеристик, которые удовлетворяют конкретные потребности определен­ного сегмента рынка или выполняют определенную задачу и разрабатываются п уста­новленном порядке на основе общего набора базовых средств. [Clements 02b, 5]

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

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

Линейки продуктов в промышленном производстве не есть нововведение. Многие историки утверждают, что концепция эта появилась в самом начале XIX века, когда Эли Уитни (Eli Whitney) начал собирать винтовки из взаимозаменяемых частей; впрочем, есть и более ранние примеры. Сегодня линейки продуктов есть в компаниях Boeing, Ford, Dell и даже McDonald’s. Каждый из этих производите­лей извлекает из общности свои выгоды. К примеру, модели Boeing 757 и 767 разрабатывались одновременно, и, несмотря на то, что эти два воздушных судна сильно отличаются друг от друга, их узлы совпадают примерно на 60 %.

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

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

♦ Благодаря методике линеек продуктов Nokia производит от 25 до 30 моде­лей сотовых телефонов в год (хотя раньше за аналогичный период удава­лось создать всего 4 модели).

♦ Компании Cummins, Inc. удалось сократить сроки производства программ­ного обеспечения для дизельных двигателей с года до недели.

♦ Со своим семейством пейджеров Motorola добилась 400-ироцентного при­роста продуктивности.

♦ По сведениям компании Hewlett-Packard, сроки выхода на рынок в рамках ее семейства печатных систем сократились в семь раз, а продуктивность увеличилась в шесть раз.

♦ На разработку первого продукта в рамках заказанного Национальным уи- раапением воздушно-космической разведки США семейства наземных стан­ций системы спутниковой связи потребовалось всего 10 % от запланиро­ванного числа разработчиков, а количество дефектов снизилось на 90 %.

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

14.2. За счет чего работают линейки программных продуктов?

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

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

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

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

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

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

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

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

♦ вспомогательного характера — все они переносятся из одного продукта и дру­гой. В наличии имеется и процесс программной разработки и целом.

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

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

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

Линейки программных продуктов основываются на повторном использовании. В то же время, как видно из эпиграфа к настоящей главе, попытки внедрить повторное использование в программной инженерии предпринимаются уже мно­го лет, и успех этого предприятия пока что под вопросом — ожидания почти все­гда оказываются радужнее реальных результатов. Причина неудач отчасти кроет­ся в том, что до последнего времени технология повторного использования распространялась под лозунгом «сконструируй, и все будет!». Любая библиотека многократного применения состоит из элементов предыдущих проектов; от раз­работчиков, прежде чем переходить к кодированию новых элементов, требуется ознакомиться с ее содержанием. У этой схемы действий слишком много недо­статков. Если библиотека невелика, разработчик, однажды не обнаружив нужно­го элемента, потеряет всякое желание продолжать поиски. Если же она слишком обширна, провести поиск будет труднее. Если искомые элементы невелики, их проще переписать, чем найти в библиотеке и модифицировать. Если они круп­ные, подробно разобраться в их назначении очень сложно, а вероятность того, что они в точности подойдут для нового приложения, крайне невелика. Проис­хождение элементов, хранящихся в библиотеках повторного использования, как правило, в лучшем случае, неочевидна. Разработчик, таким образом, не может быть полностью уверен в назначении и надежности элемента, а кроме того, он не знает условий, в которых проводилось его тестирование. В то же время точное соответствие между атрибутами качества, требуемыми в новом приложении, с од­ной стороны, и реализуемыми элементами библиотеки — с другой, практически никогда не встречается.