Системы можно конструировать на основе крупных элементов, созданных сторонними разработчиками

Линейки программных продуктов строятся на основе общей архитектуры

Линейкой, или семейством, программных продуктов называется ряд преимуще­ственно программных систем, для которых характерен общий, управляемый на­бор характеристик, реализующих потребности конкретного сегмента рынка или конкретные задачи и разработанных в установленном порядке на основе общего набора основных активов. Главным из этих активов является архитектура, спро­ектированная в расчете на удовлетворение потребностей всего семейства. Архи­тектор линейки продуктов старается выбрать для нее такую архитектуру (или семейство близкородственных вариантов архитектуры), которая сможет обслу­живать всех ее возможных участников; при этом те проектные решения, которые касаются линейки продуктов в целом, принимаются сначала, а те, которые затра­гивают только отдельных ее членов, — впоследствии. Архитектура определяет постоянные и переменные элементы линейки продуктов. Линейки программных продуктов — мощное средство мультисистемной разработки — на порядки улуч­шают такие характеристики, как срок выхода на рынок, стоимость, продуктив­ность и качество. Значимость архитектуры определяется самой сущностью этой парадигмы. Аналогично прочим капиталовложениям, архитектура линейки про­дуктов становится одним из основных активов компании-разработчика. Анализ линеек программных продуктов приводится в главе 14, а соответствующие кон­кретные примеры — в главах 15 и 17.

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

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

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

Чем меньше, тем больше: ограничивать словарь проектных альтернатив выгодно

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

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

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