19.1. Снова архитектурно­экономический цикл

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

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

• Сценарий, согласно которому компания создает на основе архитектуры не одну, а несколько систем, связанных фондом общих средств, и организует их в рамках линейки продуктов.

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

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

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

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

19.2. Создание архитектуры

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

Усовершенствовать процесс проектирования помогут ответы на ряд вопросов.

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

• Каким образом выполнено сцепление сценариев и тактик? Сцепление в из­ложенном материале производится на уровне атрибутов. Иначе говоря, сценарий генерируется согласно таблице генерации для конкретного атри­бута — скажем, производительности. Затем проводится анализ тактик, и из них отбираются те, которые с наибольшей вероятностью обеспечат дости­жение желаемого результата. Несомненно, существуют более совершенные механизмы. Рассмотрим для примера сценарий реализации производитель­ности из примера с открывателем гаражной двери из главы 7 — «При обна­ружении препятствия остановка движения двери должна быть выполнена в пределах 0,1 с». Стоит лишь задать несколько вопросов, и проблему отбо­ра тактик можно будет решить более углубленно. Возможны ли обнаруже­ние препятствия и остановка двери за 0,1 с в случае, если остальные эле­менты системы бездействуют? Если окажется, что такой возможности нет, к алгоритму обнаружения препятствия следует применить тактику «повы­шение вычислительной эффективности». Если ответ будет положитель­ным, имеет смысл сформулировать ряд вопросов о состязательности. От­веты на них помогут выбрать планировщика. Если в результате исследований удастся оформить системный метод сцепления сценариев и возможных тактик, это будет большой успех.

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

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

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

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