Затраты 10 страница

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

-РСС

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Дата добавления: 2015-04-25