Разработка и оценка архитектуры на основе сценариев

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

• 1. Выделение компонентов
• o Выбирается набор «основных» сценариев использования — наиболее существенных и выполняемых чаще других.
• o Исходя из опыта проектировщиков, выбранного архитектурного стиля (см. следующую лекцию) и требований к переносимости и удобству сопровождения системы определяются компоненты, отвечающие за определенные действия в рамках этих сценариев, т. е. за решение определенных подзадач.
• o Каждый сценарий использования системы представляется в виде последовательности обмена сообщениями между полученными компонентами.
• o При возникновении дополнительных хорошо выделенных подзадач добавляются новые компоненты, и сценарии уточняются.
• 2. Определение интерфейсов компонентов
• o Для каждого компонента в результате выделяется его интерфейс — набор сообщений, которые он принимает от других компонентов и посылает им.
• o Рассматриваются «неосновные» сценарии, которые так же разбиваются на последовательности обмена сообщениями с использованием, по возможности, уже определенных интерфейсов.
• o Если интерфейсы недостаточны, они расширяются.
• o Если интерфейс компонента слишком велик, или компонент отвечает за слишком многое, он разбивается на более мелкие.
• 3. Уточнение набора компонентов
• o Там, где это необходимо в силу требований эффективности или удобства сопровождения, несколько компонентов могут быть объединены в один.
• o Там, где это необходимо для удобства сопровождения или надежности, один компонент может быть разделен на несколько.
• 4. Достижение нужных свойств.

Все это делается до тех пор, пока не выполнятся следующие условия:

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

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

Пример работы индексатора текста.

• 1. Выделим следующие сценарии работы или модификации программы:
  • o Надо сделать так, чтобы индексатор мог работать в инкрементальном режиме, читая на входе одну фразу за другой и пополняя получаемый в процессе работы индекс.
  • o Надо сделать так, чтобы индексатор мог игнорировать предлоги, союзы, местоимения, междометия, частицы и другие служебные слова.
  • o Надо сделать так, чтобы индексатор мог обрабатывать тексты, подаваемые ему на вход в виде архивов.
  • o Надо сделать так, чтобы в индексе оставались только слова в основной грамматической форме — существительные в единственном числе и именительном падеже, глаголы в неопределенной форме и пр.
• 2. Определим две возможных архитектуры индексатора для сравнительного анализа.
• o В качестве первой архитектуры рассмотрим разбиение индексатора на два компонента. Один компонент принимает на свой вход входной текст, полностью прочитывает его и выдает на выходе список слов, из которых он состоит. Второй компонент принимает на вход список слов, а на выходе выдает его упорядоченный вариант без повторений. Этот вариант архитектуры построен в стиле «каналы и фильтры»

Архитектура индексатора в стиле «каналы и фильтры» .

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

В дополнение к этим данным имеются следующие компоненты:

1. Первый читает очередной символ на входе и передает его на обработку одному из остальных.

Если это разделитель слов (пробел, табуляция, перевод строки), управление получает второй компонент.

Если это буква — третий.

Если входной текст кончается — четвертый.

• 2. Второй компонент закачивает ввод последнего слова — оно помещается в список перед тем местом, на которое указывает ссылка, после чего последнее слово становится пустым, а ссылка начинает указывать на первое слово в списке.
• 3. Третий компонент добавляет прочитанную букву в конец последнего слова, после чего, быть может, перемещает ссылку на следующее за полученным слово в списке.
• 4. Четвертый компонент выдает полученный индекс на выход.

Эта архитектура построена в стиле «репозиторий» (см. следующую лекцию).

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

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