Компонентное проектирование как поиск 2 страница

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

Поскольку возможности и обязанности компонентов в процессе разработки си­стем выступают одним из основных источников архитектурных ограничений, но в то же время в любой системе участвует множество компонентов, компонентное проектирование системы превращается в поиск совместимых ансамблей (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ВиРСС

18.4. Пример приложения ASEILM

В этом примере мы рассмотрим информационную веб-систему, разработанную сотрудниками Института программной инженерии (Software Engineering Institute, SEI) в целях автоматизации его административных отношений с непостоянными партнерами. Создание системы автоматизированного управления лицензиатами SEI (Automated SEI Licensee Management system, ASEILM) обусловливалось сле­дующими задачами:

♦ организация распространения лицензированных институтом SEI материа­лов (в частности, курсов и комплектов для проведения оценки) среди авто­ризованных лиц;

♦ сбор административной информации для проведения оценочных меропри­ятий;

♦ графическое представление показателей дохода, посещаемости и ряда дру­гих сведений о лицензированных материалах SEI;

♦ отслеживание посещаемости курсов и отчисляемых в пользу SEI гонора­ров.

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

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

♦ Недущие специалисты ио оценке имеют право открывать новые процедуры оценки, вводить относящуюся к ним информацию и загружать комплекты для проведения оценки.

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

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

  Таблица 18.1. Требования по атрибутам качества

Атрибут качества	Требование
Функциональность	Обеспечение веб-связи с географически рассредоточенными заказчиками
Производительность	Производительность, достаточная для обслуживания заокеанских пользователей, пользующихся соединениями низкой пропускной способности (загрузка материалов на их машины должна выполняться не за часы, а за минуты)
Совместимость	Поддержка старых версий веб-браузеров, включая Netscape 3.0 и Internet Explorer 3.0
Безопасность	Поддержка нескольких классов пользователей и предоставление им услуг идентификации и авторизации
Безопасность	Организация безопасной передачи данных через Интернет на уровне коммерческого стандарта______________________________________

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

Ансамбль Miva Empressa

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

В нашем примере у группы разработчиков уже были некоторые познания относительно сервера приложений Miva Empressa, и потому они предпочли задей­ствовать его при составлении исходной гипотезы. Miva Empressa — это расшире­ние сервера Microsoft Internet Information Server (IIS), исполняющее сценарии Miva Script на основе XML. Приложения Miva Script в среде Miva Empressa ис­полняются в рамках IIS. Они способны проводить сложные вычисления — в ча­стности, обеспечивать доступ к базам данных. Они заключены в показанный на рис. 18.2 «заказной компонент». Занимательно, что это единственный компонент, который в ASEILM разрабатывался с нуля.

Рис. 18.2. Ансамбль Miva Empressa

В рассматриваемом ансамбле ASEILM, помимо сервера приложений Miva Empressa, задействуются некоторые другие коробочные компоненты:

♦ в качестве системы управления базами данных применяется Microsoft Access;

♦ графическое отображение дохода, посещаемости и прочей подобного рода информации обеспечивает приложение ChartWorks от компании Visual Mining;

♦ в качестве HTTP-сервера применяется Microsoft IIS;

♦ на серверной платформе устанавливается операционная система Windows NT 4.0.

Клиент может быть представлен любыми платформами и браузерами. В пер­воначальном ансамбле предусматривались браузер Netscape 3.0 и операционная система Windows 98. Netscape 3.0 на тот момент уже считалась устаревшей вер­сией с ограниченными возможностями, однако многие ведущие специалисты по оценке (один из видов пользователей ASEILM) продолжали ею пользоваться. Операционная система Windows 98 получила среди пользователей ASEILM се­рьезное распространение.

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

Этап 1: формулирование проектного вопроса

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

♦ Гипотеза 1. Ансамбль способен предоставить веб-доступ к данным, содер­жащимся в базе данных Access, и обеспечить их графическое представле­ние при помощи столбиковых диаграмм и других видов управленческой графики.

♦ Гипотеза 2. Данные, передаваемые между веб-браузером и НТТР-сервером, можно зашифровать средствами HTTPS.

Основная цель формулирования гипотезы 1 состояла в том, чтобы проверить функциональность системы и ее способность интегрировать требуемые компо­ненты. Гипотеза 2 позволяет подтвердить осуществимость решения одной из уста­новленных задач по атрибуту безопасности, которая заключается в обеспечении системой ASEILM безопасной передачи данных через Интернет.

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

Этап 2: установление исходных критериев оценки

Критерии оценки помогают определиться с соответствием/несоответствием ис­ходных гипотез модельному решению.

♦ Критерий 1. Модельное решение предполагает вывод в браузере диаграм­мы с данными, хранящимися в базе данных Access.

♦ Критерий 2. Между HTTP-сервером и веб-браузером должна быть органи­зована безопасная передача данных по соединению HTTPS.

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

Этап 3: определение ограничений реализации

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

Этап 4: реализация модельного решения

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

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

Сцепление меток и данных

Приложение ChartWorks описывает диаграммы на CDL (chart description langu­age — язык описания диаграмм); на нем же прописываются механизмы извлече­ния данных из базы (в этой роли в данном случае выступает Access) и их интег­рации с ней. В контексте данного ансамбля требовалось извлечь из базы данных Access метки и данные о диаграмме, причем для этого задействовались два от­дельных оператора CDL. К сожалению, CDL не предусматривает механизмов спаривания информации, сгенерированной в результате выполнения разных опе­раторов. Из-за этого возможность непосредственного запроса базы данных сред­ствами этого языка отпадает. Вместо этого запросы Access отправлялись при по­мощи Miva; в результате создавался текстовый файл, в котором сводились воедино данные и метка. Уже из этого файла при помощи CDL-оператора извлекались объединенные данные.

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

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