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

3.2.7 Использование разработки, управляемой моделями

Использование средств моделирования и работы с метаданными для продвижения по стадиям архитектурной детализации и для управления сложностью разработки программного обеспечения являются одним из аспектов разработки, управляемой моделями (Model Driven Development, MDD)^{12Сравните с методом, который мы использовали для сценария работы с внешними оценщиками, описанном в серии статей "On demand business process life cycle: Build reusable assets to transform an order processing system", которую можно найти по адресу http://www-128.ibm.com/developerworks/webservices/library/ws-odbpsum.html} . В недавно вышедшей книге серии Redbooks разработка, управляемая моделями, определяется следующим образом^{13Взято из главы "MDD and Patterns Overview", написанной Tracy Gardner, которую можно найти по адресу http://www.redbooks.ibm.com/redbooks.nsf/RedbookAbstracts/sg247105.html?Open&S_TACT=105AGX46&S_CMP=SPLT. Следующий раздел о преимуществах MDD также оттуда.} стиль разработки программного обеспечения, при котором главными артефактами являются модели, а не код.

MDD – это подход, при котором:

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

MDD предлагает подход, при котором бизнес-аналитик может зафиксировать биз- нес-процессы в модели, независимой от вычислений (Computation Independent Model, CIM). ИТ-архитектор создает модель, независимую от платформы (Platform Independent Model, PIM), а затем, в сотрудничестве с ИТ-специалистом, модель, специфичную для платформы (PSM). Модель PSM превращается разработчиками в код. Различные стадии являются инкрементными и итеративными и показаны на рис. 3.13.

увеличить изображение
Рис. 3.13. Архитектура, управляемая моделями

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

Артефакты, создаваемые на каждом этапе, должны быть определены командой разработки с использованием модели процесса, например Rational Unified Process (RUP). Хотя в данном курсе основное внимание уделяется области разработки, не менее важны и другие области – тестирование, удобство использования и управления системой, а также вопрос внедрения решения в пользовательское сообщество. Должно ли решение продаваться, предлагаться как часть обслуживания или как часть специальной разработки в пределах конкретного предприятия? Люди, работающие над этими аспектами, должны постоянно участвовать в процессе разработки, чтобы разработка, тестирование и удобство использования находились в связи с наиболее важными аспектами решения.

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

• Повышение производительности.

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

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

  MDD способствует тому, чтобы артефакты генерировались согласованно.
• Повторяемость.

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

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

  Модели облегчают понимание и обоснования системы на уровне дизайна. Тот факт, что модели являются частью определения системы, а не частью документации, означает, что модели никогда не будут устаревшими или недостоверными.
• Фиксация опыта.

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

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

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

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

3.2.8 Цепочки инструментов

Разработка, управляемая моделями? – это подход к разработке, при котором главными артефактами являются модели (а не программы). Модели могут поэтапно трансформироваться, пока не будет создан базовый код. На рис. 3.14 показан пример трансформации PIM в PSM от Object Management Group (OMG).

увеличить изображение
Рис. 3.14. Трансформация моделей

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

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

Идеалом является создание двунаправленной метамодели. Пример может выглядеть так:

1. Создание модели процесса в WebSphere Business Integration Modeler.
2. Импортирование модели в WebSphere Studio Application Development Integration Edition для реализации модели процесса, в ходе которой будут внесены изменения, включающие:
   • переименования;
   • побавление новых элементов;
   • изменение маршрутизации соединений;
   • изменение существующих элементов.
3. Повторный импорт в WebSphere Business Integration Modeler, включающий:
   • сравнение с исходной моделью;
   • повторное выполнение эмуляции;
   • изменение новой модели и повторное выполнение разработки.

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

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

На рис. 3.15 показана цепочка инструментов, на которой мы основывали нашу разработку. Бизнес-процесс фиксируется в инструменте для бизнес-моделирования бизнес-аналитиками. Эта модель используется двумя способами (см. пункт А на рис. 3.15). Она применяется для генерации определений процессов для оркестровки рабочих потоков, а также для моделирования архитектуры решения. Модель архитектуры решения содержит шаблоны, интерфейсы, модель размещения и схемы последовательностей. В оркестровке рабочих потоков процесс и архитектура рабочих потоков объединяются с последовательностью, потоками и выбранными сообщениями. Архитектурные модели и оркестровка рабочих потоков используются инструментами создания кода. На рис. 3.16 показана цепочка инструментов, которую мы применяли в этом курсе.

Рис. 3.15. Цепочка инструментов

Рис. 3.16. Цепочка инструментов, использованная в данном курсе

Используемая нами цепочка инструментов не имеет возможности для автоматического включения в модель шаблонов Patterns for e-business. Мы применили инструменты с Web-сайта Patterns for e-business для выбора шаблонов, которые потом перенесли в Microsoft Visio. После того как мы согласовали шаблоны, мы перенесли получившуюся схему размещения в Rational Software Architect.

Ниже приводится суммарный список использованных нами инструментов.

• Бизнес-процесс был разработан при помощи WBI Modeler.WBI Modeler.
• Существующие системы, такие, как Assessor Management System (Система управления оценщиками) и Document Handler (Обработчик документов), были разработаны в WebSphere Studio Application Developer.
• ESB-службы, такие, как служба рассылки оценщикам запросов о готовности к работе, были разработаны с помощью WebSphere Business Integration Message Broker Workbench.
• Рабочие потоки на FDL были импортированы в WebSphere Business Integration Modeler из WebSphere MQ Workflow Buildtime.
• Для создания архитектуры системы и решения использовался Rational Software Architect. Для целей нашего проекта Rational Software Architect дает следующие преимущества:
  • в нем есть возможность указывать артефакты, которые были разработаны в Business Integration Modeler для создания архитектуры систем;
  • он может импортировать существующие приложения из WebSphere Studio Application Developer в качестве входных данных для разработки новой архитектуры.

На основе входных данных, полученных из WebSphere Business Integration Modeler и интерфейсов имеющихся реализаций, Rational Software Architect позволяет архитектору создать интерфейсы для всех приложений, схемы классов для различных компонентов, схему последовательностей и схему размещения.

Главные артефакты, которыми архитекторы обмениваются с инструментами ИТ-специалистов, является код BPEL, FDL и WSDL. Эти спецификации интерфейсов являются входными данными для инструментов программистов. Мы использовали Web-Sphere Studio Application Developer, WebSphere Studio Application Development Integration Edition, WebSphere MQ Workflow build time и WebSphere Business Integration Message Broker workbench. Выбор инструмента зависит от того, на какой рабочей платформе ИТ-специалист будет выполнять размещение.

3.3 Заключение

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

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