Многоконтекстные системы: новые рубежи в архитектуре

Чарли Альфред (Charlie Alfred),
архитектор ПО

Март 2010 г.

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

Введение

Контекст – это несколько заинтересованных лиц, у которых одни и те же представления, приоритеты, желаемые результаты и которые зависят от одних и тех же условий и воздействий¹.Профессионалы в сфере маркетинга называют их «рыночными сегментами» и используют для формирования целенаправленной рекламы и других маркетинговых кампаний. Архитекторы могут применять контексты, чтобы определять и создавать эффективные решения для логически связанного набора сред развертывания².

В таблице 1 показан простой пример контекстов в действии. Рассмотрим лыжный курорт Thinsulate, для которого установлена предельная температура работы – -40 °С. Его описа­ние представлено в таблице 1.

Таблица 1. Пример контекста

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

Реальные примеры многоконтекстных систем

Перед тем как приступить к исследованию многоконтекстных систем, рассмотрим два реальных примера:

• Формирование маршрутов и планирование вывоза и доставки грузов в ограничен­ном районе.
• Инструменты производства полупроводников.

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

Составление маршрутов и планирование грузоперевозок

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

• Эффективность обслуживания, измеряемая количеством остановок по расписанию (в процентах).
• Уменьшение времени в пути (оплачивается вывоз или доставка груза, а не время в пути).
• Управление ограничениями по весу и вместимости транспортных средств.
• Соблюдение времени обслуживания клиентов и других физических ограничений.

В таблице 2 сведены воедино три типичных контекста для местных грузоперевозок.

Таблица 2. Контексты для местных грузоперевозок

Производство полупроводников

Производство полупроводников – процесс создания сотен микропроцессоров или чипов памяти на кремниевых пластинах размером 300 мм.

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

Каждый из этих инструментов обладает набором важных общих характеристик:

• Соответствие стандартам Международной организации полупроводникового оборудования и материалов (SEMI) – требуется для того, чтобы заводы по производству полупроводников получили возможность реализовать системы автоматизации производства для контроля всех инструментов на линии.
• Автоматизированные роботы, работающие с кассетами для полупроводниковых пластин, которые перемещают пластины между инструментами.
• Электромагнитное управление насосами, вентиляцией, манипуляторами и другими устройствами.
• Отслеживание результатов процессов по сериям, партиям и пластинам.

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

Таблица 3. Контексты для инструментов производства полупроводников

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

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

Архитектурные последствия

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

Многоконтекстный подход обеспечивает подходящую платформу для ответа на этот вопрос. Необходимо три высокоуровневых этапа:

1. Определение контекстов и характеристик.
2. Анализ контекстов путем сравнения проблем.
3. Синтез совместимых контекстов.

Анатомия контекста

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

Рисунок 1. Согласованность решения и контекста (щелкните рисунок, чтобы увеличить изображение)

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

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

Этап 1: определение контекстов и проблем.

Определение контекстов выглядит несложным. Однако качественное решение этой задачи зависит от навыков системного мышления, которое делает возможным абстрагирование и понимание произвольных систем внутри контекста. Некоторые авторы (в частности, Акофф³, Сенге⁴, Голдратт⁵, Вайнберг⁶ и Талеб⁷) написали превосходные работы, осве­щающие различные аспекты системного мышления.

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

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

• Сбор следующей информации:
• • Удостоверение личности пациента и поставщика медицинских услуг.
  • Дата и время визита.
  • Наблюдения и результаты обследования терапевта.
  • Диагноз (или возможные диагнозы), поставленные терапевтом.
  • Рекомендации терапевта относительно лечения (если имеются).
• Хранение историй болезней пациентов в базе данных, которая позволяет форми­ровать эффективные запросы по пациенту, диагнозу, временному интервалу и другим критериям.
• Быстрое формирование точных медицинских отчетов. Генерация медицинской отчетности в здравоохранении столь же важна, как вождение в индустрии грузоперевозок, и в такой же степени неприбыльна.

Один из главных моментов – существование важных типовых причин для создания медицинских отчетов. Эти типовые варианты определяют комплексы поведения и формируют начальные гипотезы для контекстов, что показано в таблице 4.

Таблица 4. Контексты медицинской отчетности

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

Этап 2: анализ контекстов путем сравнения проблем.

Первичные описания контекстов, приведенные в таблице 4, – подходящая точка отсчета. Однако чтобы лучше понять желаемые результаты и проблемы, нужно перейти на уровень выше. Мы должны точнее представлять себе, как медицинская отчетность вписывается в общую схему учреждений здравоохранения в каждом контексте.

Следует отметить чрезвычайно важный момент. Причиной множества неудачных архитек­турных и проектных решений является наивный подход.

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

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

Таблица 5. Проблемы медицинской отчетности, общие для многих контекстов

Этот анализ позволяет сформировать два достаточно очевидных заключения:

1. Контексты, основанные на лечении и на пациенте, достаточно схожи. Пять наиболее приоритетных проблем контекста, основанного на лечении, – это пункты 3–7 контекста, основанного на пациенте; они ранжированы в этом же порядке. В обоих контекстах взаимодействие с пациентами осуществляется напрямую и в обоих случаях необходим сбор данных об истории болезни, чтобы использовать во время повторных приемов пациента. Основная разница между двумя кон­текстами обусловлена размерами учреждений и тем фактом, что с каждым пациен­том взаимодействуют несколько специалистов.
2. В контексте, основанном на направлении, медицинская отчетность выполняется аналогично другим контекстам, но схожесть высокоприоритетных проблем крайне невысока. Участники контекста, основанного на направлениях, имеют высокую пропускную способность, им необходимо постоянно увеличивать ее и сокращать время от направления на процедуру до ее выполнения.

Этап 3: синтез совместимых контекстов.

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

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

Рисунок 2. Многоконтекстное оценивание(щелкните рисунок, чтобы увеличить изображение)

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

Анализ контекста

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

Архитектурные подходы

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

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

Один из способов решения проблемы – создание подсистемы обмена данными на основе сообщений, которая:

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

Адаптируемость подходов

Помимо борьбы с проблемами, каждый архитектурный подход предлагает определенный уровень гибкости. На рисунке 2 это представлено меткой (слева от каждого подхода). Данные метки при необходимости можно расширить. Ниже приведен один из возможных наборов:

• Статичность – подход фиксирован во время компиляции, механизм для внесения изменений отсутствует.
• Изменение – исходный код существует, может быть изменен и перекомпилирован.
• Конфигурация – подход аналогичен статичному или изменяемому, но параметры могут задаваться во время выполнения.
• Расширение – возможно использование подклассов для наследования или пере­определения поведения.
• Подключение модулей – использование шаблона проектирования «Стратегия»⁹, позволяющего загружать и выгружать компоненты.

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

• Исключить полностью для контекстов, основанных на направлениях.
• Полностью поддерживать для крупных контекстов, основанных на пациенте.
• Поддерживать частично (например, недоступны темы обсуждений или мульти­медийные вложения) для прочих контекстов.

Пригодность подходов

Институтом программирования ПО (Software Engineering Institute, SEI) был описан механизм оценки пригодности архитектуры ПО¹⁰. В этом подходе архитектурные решения тщательно рассматриваются на предмет того, насколько хорошо они поддерживают сценарии атрибутов качества. В нашей модели архитектурные подходы эквивалентны архитектурным решениям, которые описаны SEI, а сценарии атрибутов качества – желаемым результатам и проблемам контекстов.

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

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

• Нейтральное – подход не решает проблему и никак не воздействует на нее.
• Положительное – подход помогает решить проблему. Степень влияния может быть высокой (+++), средней (++) или низкой (+).
• Отрицательное – подход усугубляет проблему. Степень влияния может быть высокой (– – –), средней (– –) или низкой (–).

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

В примере с медицинской отчетностью пригодность можно оценить двумя способами:

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

Зависимости подходов

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

Таблица 6. Типы зависимостей между подходами

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

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

• Рассмотреть жизнеспособность использования подобного подхода (и всех подхо­дов, от которых он зависит) в контексте, основанном на направлениях.
• Определить, существует ли абстрактная стратегия, в рамках которой в подходе, основанном на направлениях, можно использовать другой механизм, отличаю­щийся от остальных.
• Определить способ «вынести за скобки» асинхронные уведомления, чтобы исклю­чить их из решения, основанного на направлениях.

Заключение

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

Примечания

1. Используемые подобным образом воздействия, как правило, являются неконтро­лируемыми факторами среды, а условия – ситуативными факторами (могут быть контролируемыми или неконтролируемыми). Важное научно-техническое откры­тие в другой отрасли является воздействием. Новый продукт, выпущенный конку­рентом и основанный на этой технологии, является условием.
2. Alfred, Charlie. “ Value-Driven Architecture: Linking Product Strategy with Architecture.” The Architecture Journal. Issue 5, July 2005.
3. Ackoff, Russell L., and Fred E. Emery. On Purposeful Systems:An Interdisciplinary Analysis of Individual and Social Behavior as a System of Purposeful Events. New Brunswick, NJ: Aldine Transaction, 2006. (Обсуждается важность синтеза и анализа, а также ключевые отличия между системами, стремящимися к достижению нескольких целей, и целенаправленными системами.)
4. Senge, Peter. The Fifth Discipline: The Art and Practice of theLearning Organization. Rev. ed. New York: Doubleday/Currency, 2006 г. (Содержит превосходное обсужде­ние динамики систем и способов, которыми она моделируется и которыми пере­даются сообщения.)
5. Goldratt, Eliyahu M., and Jeff Cox. The Goal: A Process of OngoingImprovement. Third rev. ed. Great Barrington, MA: North River Press, 2004 г. (Представлена теория ограничений и требование определения доминирующего ограничения и воздей­ствия на него.)
6. Weinberg, Gerald M. Rethinking Systems Analysis & Design. New York: Dorsett House Publishing Co., 1988. (Обсуждается системное мышление как ускоритель обучения, а также важность контекста.)
7. Taleb, Nassim Nicholas. The Black Swan: The Impact of the HighlyImprobable. New York: Random House, 2007. (Обсуждается значительная роль неопределенности и уязвимости человека от маловероятных событий.)
8. (Планирование задач в установленном промежутке времени – архитектурный подход, используемый в ОС реального времени. Атомарность, согласованность, изолированность, долговечность транзакций – архитектурный подход к системам управления реляционными базами данных (СУБД).)
9. Gamma, Erich, Richard Helm, Ralph Johnson, John Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Reading, MA: Addison-Wesley Professional, 1994.
10. Clements, Paul, Rick Kazman, and Mark Klein. Evaluating SoftwareArchitectures: Methods and Case Studies. Boston, MA; London: Addison-Wesley Professional, 2001.
11. Таким образом разрешаются двунаправленные зависимости, то есть подход A сильно зависит от подхода B, а подход B имеет слабую зависимость от A либо не зависит вовсе.

Об авторе

Чарли Альфред (charliealfred@comcast.net) имеет 30-летний опыт разработки про­граммного обеспечения, последние 10 лет он является архитектором ПО. За это время он поработал с несколькими типами системам, включая системы управления в реальном времени, обработки транзакций, оптимизации и линии программных продуктов. Г‑н Альфред проживает с семьей в г. Нашуа, штат Нью-Гемпшир.