18.3. Компонентное проектирование как поиск

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

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

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

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

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

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

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

Прототип, находящийся в конкретном проектном контексте, называется модельным решением (model solution). В зависимости от серьезности риска,

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

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

Рис. 18.1. Последовательность действий при решении модельной задачи

На рис. 18.1 изображена последовательность действий при решении модельной задачи. Процесс этот состоит из шести последовательно выполняемых этапов:

1. Архитектор вместе с инженерами формулируют проектный вопрос (design question). Ссылающийся на неизвестное, выраженное гипотезой, проект­ный вопрос инициирует модельную задачу.

2. Архитектор с инженерами устанавливают исходные критерии оценки (starting evaluation criteria). В них описывается механизм подтверждения/опровер­жения гипотезы в модельном решении.

3. Архитектор с инженерами определяют ограничения реализации (implemen­tation constraints). Они устанавливают фиксированную (негибкую) часть проектного контекста, которая регулирует реализацию модельного реше­ния. Среди такого рода ограничений фигурируют требования по платфор­ме, версии компонентов и бизнес-правила.

4. В заданном проектном контексте инженеры вырабатывают модельное ре­шение (model solution). Модельное решение представляет собой минималь­ное приложение, обращающееся только к тем характеристикам компонента (или компонентов), которые необходимы для подтверждения или опровер­жения гипотезы.

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

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

Оставшаяся часть главы отведена под пример и иллюстрацию применения перечисленных этапов при разработке веб-приложения ASEILM.

О, АТАМ, ГДЕ ТЫ?

Речь в этой главе идет о том, как определить соответствие отобранного ансамбля компонен­тов выставленным к системе требованиям по качеству и поведению. Очевидно, это архитек­турный вопрос. Так почему же мы не решаем его методом архитектурной оценки — напри­мер, методом АТАМ? В конце концов, задача АТАМ состоит именно в том, чтобы оценить архитектурные решения (в том числе решение о применении компонентов, определенным образом «смонтированных» друг с другом) в свете предъявляемых к системе требований по качеству и поведению. Почему просто не «провести здесь оценку по методу АТАМ», и все на этом?

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

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

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

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

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

После завершения процесса проверки ансамбля на правильность для него (равно как и для архитектуры системы в целом) можно смело проводить архитектурную оценку по методу АТАМ или no любому другому методу.

- LJВиРСС