Моделирование. Наш метод

3.2.6 Процесс использования модели активов Patterns for e-business

Подход, который мы используем в главе 5, "Архитектура системы", при разработке решения для работы с внешними оценщиками, включает применение процесса выбора шаблонов Patterns for e-business (рис. 3.10).

увеличить изображение
Рис. 3.10. Процесс выбора шаблонов Patterns for e-business и многоуровневая модель активов

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

Недавно был разработан метод на основе UML2 для применения процесса выбора шаблонов к шаблонам интеграции процессов.

Принципы процесса

На рис. 3.11 дается общий обзор подхода Process Integration Design Approach (PIDA)^{9Подход PIDA был защищен патентом в бюро патентов Великобритании (GB920040072GB1 – METHOD AND APPARATUS FOR INTEGRATING ELECTRONIC SYSTEMS). См. также презентацию автора этого патента, Paul Verscheuren, "Business Integration Patterns", которую можно найти по адресу http://www-106.ibm.com/developerworks/patterns/library/w19.pdf} . В этом подходе выделяется несколько характерных аспектов.

увеличить изображение
Рис. 3.11. Подход к разработке решений по интеграции процессов

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

Мы выбрали этот метод проектирования интеграции в силу ряда причин:

• Команда ранее использовала Patterns for e-Business для проектирования архитектуры интеграции и сочла этот метод эффективным.
• Метод UML-моделирования мы, напротив, посчитали сложным для применения к моделированию интеграции существующих решений. В литературе, как правило, основное внимание уделяется построению новых решений с разработкой компонентов и классов с нуля и существует очень мало практических руководств по использованию UML для моделирования добавления одной-двух возможностей в сложную систему. Сочетая применение Patterns for e-Business и UML, подход PIDA позволяет использовать UML для моделирования интеграции уже существующих сложных систем.

Кооперация и взаимодействие

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

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

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

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

Рис. 3.12. Фрактальное разделение взаимодействия

Важный момент состоит в том, что представление вверху не менее правильно, чем представление внизу. Оба они отражают одну и ту же модель, но по-разному. Можно представить себе UML-редактор, способный переключаться между такими представлениями.

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

Важные термины

Приведенные ниже концепции важны для понимания технологии Patterns for e-business.

Проблемы существующей и будущей системы

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

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

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

Качество обслуживания

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

Критерий QoS: управление

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

Выявление функциональных требований

Что касается функциональных требований, то они определяются прецедентами использования (Use Case) на уровне дизайна системы. Прецеденты использования описывают желательное поведение системы, которое выражается на уровне бизнеса через бизнес-сценарии и бизнес-процессы. В контексте интеграции процессов функциональное содержание в первую очередь выражается связями-взаимодействиями, которые, в свою очередь, определяют топологию системы. Так что мы можем назвать функциональные требования топологическими требованиями.

Итак, существует два типа требований к системе:

Рабочие продукты и метод работы

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

Мы не предполагаем, что рабочие продукты и метод, которые мы здесь описываем, будут использоваться как процесс, которому необходимо следовать. Идея, лежащая в основе такого подхода, состоит в том, что этот подход включается в вашу конкретную методологию и информирует вас о том, как на практике следует выполнять различные задачи, например выбор подходящего шаблона для электронного бизнеса, если вы используете дизайн на основе Patterns for e-business. Мы применяем данный подход в контексте применения многоуровневой модели активов Patterns for e-business^{10Существует ряд внутренних исследований IBM, в которых показывается, как данный подход работает в сочетании с IBM Global Services Method, с Rational Unified Process (RUP) и с методами корпоративной архитектуры (EA), такими, как Technical e-Business Architecture Method (TeAM). Обращайтесь по адресу swithers@uk.ibm.com} .

Данный метод включает в себя следующие задачи:

1. Определение границ решения в терминах, описывающих возможности, поведение и технические аспекты:
   • определить целевой контекст (состояние), который мы хотим получить в будущем;
   • определить текущий контекст (состояние), которое мы имеем сегодня.
2. Уделить внимание кооперациям в том контексте, в котором они возникают. Главная задача интеграции процессов состоит в том, чтобы перераспределить кооперации в новом контексте, а не создавать новые.
3. Использовать фрактальную природу модели в процессе детализации:
   • Изучать взаимосвязи между компонентами. Чтобы рассмотреть их более подробно, разделите компонент на составляющие и изучите связи между составляющими. Сам компонент при этом является "черным ящиком".
   • Границы между компонентами, т. е. интерфейсы, являются наиболее важным аспектом, информация о котором передается из одной стадии детализации в другую. Архитектор отвечает за определение уровня детализации и решает, что следует передавать ИТ-специалисту или разработчику приложений для дальнейшей детализации.
   • Передача такой информации формирует контракт, соответствующий понятию "проектирование по контракту".
4. В соответствии с таким понимание природы проблемы работу архитектора следует организовать согласно простому шаблону, называемому Distribute-Recurse-Converge (Разделение-возврат-слияние):
   • Начните с двух схем – текущего и будущего контекста.
   • Разделение. Применяйте к системе различные сценарии и прецеденты использования, чтобы выявить необходимые кооперации:
     • создайте список коопераций для дальнейшего анализа;
     • определите общую топологию решения.
   • Возврат. Проанализируйте каждую кооперацию до взаимодействий. Кооперации первого уровня будут превращаться в более детальные кооперации до тех пор, пока мы не доберемся до единичных событий – взаимодействий.
   • На каждом уровне анализа добавьте требования QoS к каждой кооперации.
   • Слияние. Сведите вместе разные ветви анализа, убедитесь, что они совместимы и что получающаяся система хорошо сбалансирована в плане удовлетворения разных требований.

Фрактальное мышление

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

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

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

Решения, принимаемые на разных уровнях

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

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

• известны все значимые элементы;
• проявились все внешние ограничения, влияющие на решение.

Решения принимаются на том уровне анализа, на котором они могут быть полностью оправданы. Этими уровнями могут быть:

• очень ранняя стадия, например если заказчик выбрал для построения интеграции WebSphere Application Server;
• верхний уровень коопераций, например если бизнес требует двух разных режимов работы – прямого доступа клиентов и пакетных заданий;
• в момент выбора продуктов, например если мы не можем использовать продукт Х из-за того, что требуются компенсаторные транзакции;
• это может быть даже стадия окончательного слияния, например если мы должны использовать кластеры для обеспечения выполнения требований по высокой доступности системы.

Метод с проведением семинаров и разработкой по контракту вполне поддерживает применение данного подхода.