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

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

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

 

14.3. Определение области действия

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

Рис. 14.1. Пространство всех возможных систем подразделяется на несколько участков: внутри области действия (белая), вне области действия (в крапинку) и предполагающие дифференцированное рассмотрение (черная) (Приводится по изданию [Clements 02b] (адаптированная версия).

 

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

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

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

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

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

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

♦ GM Powertrain, собирая продукты из базовых средств линейки, основыва­ется на контрактах, хранящихся в базе данных. Каждый элемент снабжает­ся четко определенными интерфейсами и возможными изменяемыми пара­метрами. Проводя в базе данных поиск желаемых характеристик, этот инструмент производит сборку продукта.

Линейки продуктов с широкой областью действия, как правило, разрабатыва­ются по подобию каркасов или коллекций служб. Нижеследующие примеры — тому подтверждение.

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

♦ Система Luther (см. главу 17) представляет собой линейку продуктов, скон­струированную поверх J2EE (каркас). В ходе разработки каждого продукта конструируется пользовательский интерфейс и реализуются вспомогатель­ные прикладные модули.

НЕ ВСЕ ТАК ПРОСТО

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

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

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

К неудаче при попытке внедрения линейки продуктов способны привести следующие факторы:

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

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

♦ нежелание менеджеров среднего звена отказаться от единоличного контроля над проек­тами;

♦ нечеткое формулирование коммерческих задач, обусловливающих внедрение методики линеек продуктов;

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

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

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

Джо Гэймер (Joe Gahimer) из компании Cummins, Inc. (производителя крайне успешной линейки программных продуктов, рассматриваемой в работе [Clements 02b]) рассказывает о двух задействованных в продуктах компании элементах, владельцы которых были уверены в их неповторимости. По их мнению, схожесть регулятора скорости и регулятора гребного вала сводилась лишь к тому, что оба контролируют скорость. Tщательно зафиксировав дета­ли обоих приложений, участники группы базовых средств в конце концов выяснили, что эле­менты эти не только схожи, но и функционально идентичны — разница лишь в значениях кон­стант.

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

-РСС

14.4. Варианты архитектуры линеек продуктов

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

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

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

♦ выявить изменяемые параметры;

♦ обеспечить поддержку изменяемых параметров;

♦ оценить архитектуру на предмет пригодности к построению линейки про­дуктов.

Установление изменяемых параметров

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

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

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

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

Обеспечение изменяемых параметров

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

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

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

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

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

♦ В объектно-ориентированных системах изменчивость достигается за счет специализации или обобщения конкретных классов. Учитывать возмож­ность написания (по мере необходимости) специализаций для различных продуктов следует еще на этапе составления классов.

♦ Встраивание точек расширения в реализацию элемента. Они помогают без­болезненно вводить новые варианты поведения и дополнительную функ­циональность.

♦ Реализовать изменчивость можно путем введения в элемент, подсистему или в совокупность подсистем параметров периода производства, которые через установку ряда значений позволяют конфигурировать продукт.

♦ Рефлексией называется способность программы управлять данными о се­бе, своей среде исполнения и состоянии. Рефлексивные программы могут корректировать собственное поведение в зависимости от контекста.

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

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

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