Компания IBM
Опубликован: 14.08.2008 | Доступ: свободный | Студентов: 1090 / 150 | Оценка: 4.75 / 3.75 | Длительность: 27:55:00
Лекция 3:

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

< Лекция 2 || Лекция 3: 12345 || Лекция 4 >

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

Примечание. В этом и следующем разделе мы ссылаемся на книгу серии IBM Redbooks под названием "Patterns: Model-Driven Development Using IBM Rational Software Architect", SG24-710511Имеется русский перевод этой книги – "Шаблоны: управляемая моделями разработка в среде IBM Rational Software Architect". М., 2006 г. Примеч. пер .: http://www.redbooks.ibm.com/redbooks.nsf/RedbookAbstracts/sg247105.html?Open&S_TACT=105AGX46&S_CMP=SPLT

Использование средств моделирования и работы с метаданными для продвижения по стадиям архитектурной детализации и для управления сложностью разработки программного обеспечения являются одним из аспектов разработки, управляемой моделями (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 Заключение

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

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

< Лекция 2 || Лекция 3: 12345 || Лекция 4 >
Надежда Белякова
Надежда Белякова
Россия
Pavel Pelevin
Pavel Pelevin
Украина, Одесса