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

3.2.2 Области ответственности и разработка по контрактам

В нашем методе все эти многочисленные роли работают вместе на каждой стадии разработки. В ходе разработки создаются промежуточные продукты, такие, как модель бизнес-процесса и документ архитектуры решения. Эти документы формируют контракты между членами команды и являются маркерами продвижения проекта в целом. Такой процесс не является в строгом смысле каскадным^{6Waterfall – каскадная разработка или методика "водопада". Примеч. пер .}, поскольку работа над моделью бизнес-процесса происходит параллельно с работой над архитектурой решения и некоторыми частями реализации. Тем не менее работа организована в форме стадий, с конечными продуктами и формальным утверждением завершения каждой стадии. В определенных пределах платформа разработки программного обеспечения может поддерживать и итеративную разработку через использование таких механизмов, как реорганизация кода (рефакторинг), а также существуют большие возможности для параллельной работы, но разработка должна вестись стадиями, поскольку изменения сложно преобразовать обратно в модель процесса.

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

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

Мы выбрали подход, в котором бизнес-аналитик документирует бизнес-процесс с помощью WebSphere Business Integration Modeler и рассматривает модель как спецификацию для программирования. Архитектор и ИТ-специалисты могли произвольно использовать, дополнять и изменять модель в соответствии с целями реализации. Модель не является жестким и стабильным описанием работы процесса.

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

На рис. 3.6 иллюстрируется три разных способа понимания взаимосвязи между бизнес-моделью и ИТ-моделью.

Рис. 3.6. Разные подходы к реализации бизнес-модели

• Бизнес-аналитик разрабатывает модель процесса и экспортирует ее (на рисунке пункт А). ИТ-архитектор рассматривает модель процесса как спецификацию требований к процессу и может импортировать для помощи в разработке ИТ-модели всю модель, ее часть или вообще ничего не импортировать.
• Бизнес-аналитик разрабатывает модель процесса и экспортирует ее (на рисунке пункт В). ИТ-архитектор импортирует модель, а затем продолжает разработку этой модели. Бизнес-аналитик может снова импортировать ИТ-модель, поскольку во всех случаях используется общий язык – BPEL, и принять ИТ-детализацию. Существует опасность, что ИТ-детализация сделает ключевые элементы модели непонятными для бизнес-аналитика.
• При подходе С у нас есть общее представление бизнес-компонентов и процессов, над которым бизнес-аналитик и ИТ-архитектор работают вместе. Цель в том, чтобы найти разные абстракции одних и тех же бизнес-процессов и компонентов, подходящие для моделирования как бизнес-аналитику, так и ИТ-архитектору.

Это почти зрелая модель технологии моделирования автоматизированных бизнес-процессов. Пункт (А) соответствует обычно используемым графическим технологиям, от рисунков на клочках бумаги к Visio и к организованным инструментам моделирования бизнес-процессов, таким, как WebSphere Business Integration Modeler. Пункт (В) соответствует существующим инструментам, основанным на исполняемых языках процессов, таких, как BPEL, и отражает собой современный уровень технологии. Пункт (С), возможно, отражает путь, по которому технология пойдет дальше.

Три контракта

Мы идентифицировали три главные фазы разработки архитектуры на основе детализации модели решения (рис. 3.7). Это дало нам три контракта. Первая фаза рассматривается в "Моделирование. Бизнес-процесс" , "Бизнес-процесс", и представляет собой разработку модели бизнес-процесса. Такая бизнес-модель называется "моделью, независимой от вычислений" (Computationally Independent Model, CIM). Она пишется на BPEL, который служит языком описания процесса.

Рис. 3.7. Контракты между ролями, задействованными в реализации процесса

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

   Разработка архитектуры описывается в лекции 5, "Архитектура системы", и в "Моделирование. Архитектура решения" , "Архитектура решения". Показывается, как архитектор решения включает бизнес-модель, созданную в WebSphere Business Integration Modeler, в платформо-независимую модель (platform independent model, PIM), разработанную в Rational Software Architect.

   Модель PIM должна быть изучена бизнес-аналитиком на предмет проверки того, не было ли при детализации выявлено новых проблем в процессе и не было ли неправильной интерпретации целей бизнес-процесса.
2. Модель PIM формирует контракт между архитектором решения и бизнес-аналитиком, который проверяет, реализует ли архитектура решения бизнес-модель.

   Архитектор с помощью ИT-специалистов и архитектора инфраструктуры переводит PIM в платформоспецифическую модель (platform specific model, PSM), используя технологии, имеющиеся в компании LGI. Переходу решения к PSM посвящен конец главы 5 и вся глава 6. Модель PSM должна быть утверждена архитектором ИТ-инфраструктуры и просмотрена ИТ-специалистами.
3. Модель PSM формирует контракт между архитектором решения, архитектором инфраструктуры и ИТ-специалистами, которые отвечают за разработку реализации решения.

3.2.3 Сбор бизнес-требований на семинарах по моделированию

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

Еще одно преимущество подхода с использованием семинаров состоит в том, что такой подход играет важную роль объединении всей команды, задействованной в руководстве проектом, в создании решения и в конечном счете в его применении. При этом создается работоспособное решение, и используются выгоды, которое оно дает. Существует ряд опасностей, возникающих, когда проблемы программных инженеров приобретают слишком большой вес при построении решения, и это хорошо описано в работе Алана Купера (Alan Cooper) "The Inmates Are Running the Asylum: Why High Tech Products Drive Us Crazy and How to Restore the Sanity"^{7Издательство "Macmillan, 1999, ISBN 0-672-31649-8".}. Раннее вовлечение в обсуждение всех, кого касается изменение бизнес-процесса, является ключом к успеху.

Чтобы такое участие было эффективным, оно должно быть организовано и должно приниматься всеми представителями заинтересованных сторон. Существует ряд книг, специально посвященных переработке бизнес-процессов, в которых уделяется внимание сбору информации о существующем бизнес-процессе и выполнению задачи по его совершенствованию. Можно начать с книги серии Redbooks под названием "Continuous business process management", SG24-6590, которую можно найти по адресу http://www.redbooks.ibm.com/abstracts/sg246590.html?Open.

В этой книге описывается один из методов разработки бизнес-процессов, специально ориентированный на платформу WebSphere версии 4.

Разработка нового бизнес-процесса и его автоматизация – это лишь часть общей задачи по перестройке бизнеса. Разработка нового бизнес-процесса должна быть частью более обширной задачи реализации изменения. Модель процесса – это эффективный способ организации обсуждения бизнес-процесса с руководителями и пользователями бизнес-процесса^{8Существует очень хорошо описанный пример, предлагаемый Chris Booth из Strategic Thought в книге автора Charles Brett под названием "Five Axes of Business Application Integration". Этот пример основывается на работе с Criterion Assurance, и он показывает пользу применения моделей процесса на семинарах, посвященных требованиям, для общего успеха проекта.}.

3.2.4 Создание базовой архитектуры

Создание высокоуровневой архитектуры начинается с самых ранних стадий проектирования решения. Как показано в модели на рис. 3.8, спецификации архитектуры со временем переходят от исходных, самых высокоуровневых концептуальных представлений к детальным, специфическим представлениям физического уровня. Стадии, через которые мы проходили, пронумерованы цифрами от 1 до 4.

увеличить изображение
Рис. 3.8. Использование шаблонов и активов в жизненном цикле

1. Наш архитектурный процесс начинается с использования шаблонов для электронного бизнеса (Patterns for e-business) для создания базовой архитектуры. Шаблоны для электронного бизнеса очень полезны при создании высокоуровневой архитектуры. Ключевым свойством этих шаблонов является четко определенный процесс выбора шаблонов. Процесс выбора шаблонов ускоряет работу по проектированию и обеспечивает возможность проследить ход работы от бизнес-требований до принятия решений по архитектуре. Процесс выбора шаблона начинается с анализа небольшого числа архитектурно-значимых требований и движущих сил. Эта информация образовывает высокоуровневую топологию приложения и рабочей системы, удовлетворяющую нуждам бизнеса и интеграции. Использование метода Patterns for e-business описывается в следующем разделе и рассматривается в разделе 5.1, "Выбор архитектурных шаблонов".
2. Документирование базовой архитектуры с помощью UML с использованием Rational Software Architect. В базовой архитектуре определяются технологии, которые будут применяться, а также компоненты, которые будут создаваться и размещаться. Эта информация необходима для того, чтобы архитектор инфраструктуры мог планировать физическое размещение, а ИТ-специалисты могли определить, какие технологии нужно использовать для создания компонентов.
3. Третий этап – это анализ взаимодействий и интерфейсов с целью предоставления ИТ-специалистам UML-модели решения, WSDL-определений интерфейсов и BPEL-описаний бизнес-процесса. Мы выполним эту детализацию в "Моделирование. Архитектура решения" , "Архитектура решения".
4. Этапы, связанные с проектированием, реализуют ИТ-специалисты, и мы расскажем о них в следующих главах, посвященных реализации.

3.2.5 Многоуровневая модель активов Patterns for e-business

Значительная часть проектирования архитектуры выполняется с помощью много-уровневой модели активов Patterns for e-business.

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

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

Эти активы и их взаимосвязи друг с другом показаны на рис. 3.9.

Рис. 3.9. Многоуровневая модель активов Patterns for e-business

Web-сайт Patterns for e-business

Web-сайт Patterns for e-business предоставляет простой способ навигации по многоуровневой модели активов с целью определения активов, наиболее подходящих для конкретной ситуации.

За справками обращайтесь на сайт Patterns for e-business: http://www.ibm.com/developerWorks/patterns/