Параметрические модули

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

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

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

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

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

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

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

Архитектура, впрочем, продемонстрировала себя основой всей методики — как с технической, так и с культурной точки зрения. В некотором смысле, она оказа­лась тем осязаемым объектом, создание и конкретизация которого заявлялись как конечная цель. В силу своей значимости архитектура оказалась в высшей степени видимой. Власть над ней, но, с другой стороны, и ответственность за ее развитие ложилась на участников компактной, высокопрофессиональной группы архитекторов. В результате была достигнута та «концептуальная целостность» архитектуры, которую Брукс [Brooks 95] считает основным условием успеха лю­бого программного проекта.

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

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

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

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

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

Есть два сообщения, повествующие о переходе CelsiusTech к методике постро­ения линейки продуктов. Первое — составленное сотрудниками Института про­граммной инженерии [Brownsword 96] — послужило основным источником ма­териала для данной главы. Второе — это диссертация, защищенная в шведском университете г. Линкопинг [Cederling 92].

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

1. Можно ли на основе архитектуры CelsiusTech создать систему управления воздушным движением наподобие описанной в главе 6? Могла ли Celsius­Tech, напротив, обратиться к архитектуре этой системы? В чем сущност­ные различия между двумя вариантами архитектуры?

2. В период разработки линейки продуктов SS2000 структура управления CelsiusTech несколько раз претерпевала изменения. Учитывая высказан­ный нами в главе 7 тезис о том, что структура продукта должна отражать структуру проекта, оцените воздействие этих изменений.