Одной из наших целей, обозначенных в разделе 1.3, "Цели и ограничения,
связанные с информационными технологиями", является повышение производительности
разработки при использовании современных инструментов
и технологий. Новая система реализует
В этой лекции мы опишем метод, который мы используем при создании
решения для работы с внешними
Что такое бизнес по требованию (On Demand Business)? IBM определяет его как бизнес, руководители которого могут видеть свою компанию и управлять ею как единым целым. Это означает, что все отрасли бизнеса должны задействовать друг друга в ходе динамических преобразований ранее изолированных операций, проводимых отдельными подразделениями, в цельный интегрированный бизнес-процесс, охватывающий всю компанию, а также клиентов за ее пределами.
Бизнес по требованию имеет четыре наиболее существенные характеристики:
За дополнительной информацией о бизнесе по требованию обращайтесь на сайт http://www-306.ibm.com/e-business/ondemand/us/overview/overview.shtml
Компания LGI преобразует себя в бизнес по требованию следующим образом:
Преобразуя свою ИТ-инфраструктуру в инфраструктуру на основе открытых стандартов, что делает LGI более гибкой и готовой к ответу на изменение нужд бизнеса.
При разработке решений акцент делается на новых или более эффективных бизнес-процессах, включающих в себя клиентов, подразделения и поставщиков.
Формирование разработки программного обеспечения является стратегическим бизнес-процессом, который определяет успех бизнеса и который должен направляться горизонтальной интеграцией того же типа, что и другие бизнес-процессы.
Операционная среда, работающая по требованию, имеет две цели – упрощение
работы с ИТ и повышение гибкости бизнеса. Она представляет собой набор средств
управления интеграцией и инфраструктурой, который на модульной и инкрементной
основе может использоваться клиентами и партнерами для обеспечения перехода
к бизнесу по требованию. Эта среда состоит из двух частей – управление инфра-структурой
и управление интеграцией, которые решают задачи упрощения работы
с ИТ и повышения гибкости бизнеса. Обращайтесь к книге серии IBM Redbook под
названием "On Demand
Управление инфраструктурой – это создание консолидированного логического
представления о ресурсах сети, а также обеспечение доступа к этому представлению.
Интеграция – это такое соединение людей, процессов и информации, которое позволяет
компаниям более гибко отвечать на динамические изменения рынков, клиентского
и
(рис 3.1) Операционная среда по требованиюВ решении для работы с внешними
Интерес к сервис-ориентированному моделированию возрастает в связи с пониманием
того, что существующие процессы разработки и нотации, такие, как объектно-ориентированный
анализ и проектирование (
Место, которое занимают OOAD, EA и
(рис 3.2) Позиционирование BPM, EA и OOAD (Zimmerman et al., Service-Oriented Analysis and Design)Этими методами занимаются разные люди. EA – это сфера деятельности
архитекторов предприятия, решений и инфраструктуры;
Идея упомянутых авторов состоит в том, что каждый из процессов, OOAD, EA
и
В разделе 3.1.3, "Платформа разработки программного обеспечения от IBM", описывается стратегия, лежащая в основе платформы разработки от IBM, ориентированная на интеграцию различных ролей и операций, задействованных в разработке программного решения.
IBM рассматривает разработку программного обеспечения как стратегический
бизнес-процесс. Разработка выигрывает от горизонтальной интеграции как любой
другой бизнес-процесс. IBM основывает свои инструменты разработки программного
обеспечения на общей платформе разработки (software
(рис 3.3) Разработка программного обеспечения: стратегический бизнес-процессПлатформа разработки программного обеспечения от IBM предлагает более широкий инструментарий для операционной среды по требованию, чем отдельные методологии разработки программного обеспечения. Данная платформа позволяет интегрировать разные подразделения, процессы и конечные продукты, задействованные в разработке программ, а также интегрирует конкретные инструменты.
Платформа разработки программного обеспечения от IBM преследует следующие цели:
Моделирование бизнес-процессов, моделирование информации и Rational Unified Process $$\text{\textregistered}$$ являются основными средствами соединения нужд бизнеса с ИТ-решениями.
Мы уделим основное внимание использованию моделирования бизнес-процессов
для соединения нужд бизнеса с ИТ-решением в сценарии работы с внешними
Программная платформа Eclipse в сочетании с каркасом Eclipse Modeling Framework
(
(рис 3.4) Платформа разработки программного обеспечения (Alan Brown в упомянутой работе)Инструменты, разработанные на основе нужд исполнителей конкретных ролей,
но с интеграцией на общей инструментальной платформе позволяют осуществлять
совместное использование артефактов с применением общей
Все используемые нами инструменты работают на платформе Eclipse и имеют общие характеристики. В частности, мы сконцентрируемся на следующих интеграционных задачах:
Rational Unified Process (RUP $$\text{\texttrademark}$$ ) – это основной инструмент, обеспечивающий полную видимость, снижение затрат и управление рисками в ходе разработки программного обеспечения.
В данном проекте мы не использовали RUP для определения процесса разработки
и управления им,
Подход, который использовался группой System
Этот метод описывается в следующих разделах:
Разработка решения для взаимодействия с внешними
В разработке участвуют следующие роли:
Роль бизнес-куратора состоит в том, чтобы задавать общие цели проекта работы
с внешними
Куратор будет лишь ограниченно привлекаться к повседневной разработке. Он будет использовать графические изображения бизнес-процесса и отчеты инструмента Modeler для создания презентаций с целью формулирования экономического обоснования и разъяснения предлагаемых изменений процесса для руководителей остальных отделов компании.
Один или несколько представителей от сообщества пользователей, в частности
Представители пользователей будут применять создаваемые графики для создания презентаций с целью разъяснения и обсуждения изменений со своими коллегами.
Менеджер проекта отвечает за выпуск решения для работы с внешними
Менеджер проекта будет сотрудничать с бизнес-аналитиком и использовать отчеты инструмента Modeler для формирования задач и областей ответственности.
Эта роль отвечает за проведение семинаров. Ее может выполнять менеджер проекта, бизнес-аналитик или специалист по процессам или кто-то, имеющий специальный опыт проведения семинаров. Важный момент состоит в том, что этот человек отвечает за проведение семинаров и за документирование их результатов.
Ответственный за документирование семинаров будет использовать WebSphere Business Integration Modeler или Microsoft Visio $$\text{\textregistered}$$ для записи моделей процесса. Продвижение в создании модели процесса может записываться после каждого семинара. В качестве альтернативы, если это удовлетворит всех участников, более эффективной будет интерактивная работа с инструментом с использованием проектора или же общего экрана (при дистанционном семинаре).
Бизнес-аналитик отвечает за бизнес-процессы, существующие в страховой
компании LGI. Аналитик отвечает перед бизнес-куратором за достижение целей,
поставленных для процесса автоматизации работы с
Бизнес-аналитик выполняет следующие задачи:
Бизнес-аналитик будет использовать WebSphere Business Integration Modeler. Он также будет использовать инструмент для создания и документирования процесса, определения измеряемых параметров, относящихся к целям, установленным для решения, и для эмуляции бизнес-процесса с целью проверки достижения поставленных целей.
ИТ-архитектор решения отвечает за связь нового процесса работы с внешними
Архитектор решения выполняет следующие задачи:
Главный инструмент, который должен применять архитектор решения, – это
Rational
Главной областью ответственности архитектора предприятия является определение стандартов для ИТ-инфраструктуры и стратегических ИТ-целей для бизнеса. Архитектор инфраструктуры отвечает за понимание стандартов и целей ИТ-инфраструктуры и за обеспечения соответствия новых решений этим стандартам и целям. Кроме этого, данный архитектор отвечает (хотя это и не входит в наш сценарий) за планирование пропускной способности, выполнение требований по времени ответа и уровню обслуживания, за обслуживание ИТ-инфраструктуры, отказоустойчивость, а также за резервное копирование и восстановление системы.
Архитектор данных отвечает за моделирование корпоративных данных, за определение таблиц баз данных и связей между ними. Он должен иметь глубокое понимание бизнеса, а также технические знания в области реляционных моделей данных.
В этом тексте мы опустили все вопросы, связанные с моделями данных, поскольку основное внимание мы уделяем интеграции на основе процессов. Когда нам нужно будет выбрать инструменты для моделирования и построения решения, вопросам, связанным с данными, будет уделено самое пристальное внимание.
В данном сценарии мы опускаем все вопросы, связанные с безопасностью, защитой личных данных и с соответствием законам о защите информации и другим законодательным актам.
ИТ-архитектор может обращаться к ИТ-специалистам на ранних стадиях разработки с целью выяснения того, как работает существующая система. Если специалисты будут присутствовать на ранних семинарах по проектированию процесса, это будет полезно, поскольку они будут уточнять дизайн. Специалисты смогут проверить, имеет ли модель процесса достаточную детализацию, чтобы с ней можно было работать.
Главной областью ответственности ИТ-специалистов является экспортирование
модели процесса, созданной бизнес-аналитиком (BPEL), из WebSphere Business
Integration Modeler, модели, созданной ИТ-архитектором (UML), из Rational Software
(рис 3.5) Роли, участвующие в создании решенияРазработчики приложений выполняют следующие задачи:
У нас было четыре ИТ-специалиста. Мы объединили роли, связанные с разработкой и обслуживанием рабочей системы, поскольку основное внимание мы уделяем разработке, а единственная задача, относящаяся у нас к рабочей системе, – это ее размещение:
Специалист по
Главным инструментом этого специалиста является
Этот специалист отвечает за базовую инфраструктуру
Этот специалист отвечает за реализацию нового BPEL-процесса работы с
внешними
Специалист по WebSphere Application Server отвечает за создание
и размещение служб, используемых для автоматизации обработки претензий.
Мы употребили для создания служб WebSphere Studio
В нашем методе все эти многочисленные роли работают вместе на каждой стадии
разработки. В ходе разработки создаются промежуточные продукты, такие, как модель
бизнес-процесса и документ архитектуры решения. Эти документы формируют
контракты между членами команды и являются маркерами продвижения проекта
в целом. Такой процесс не является в строгом смысле
Как говорится в разделе 3.2.8, "Цепочки инструментов", сегодня существуют ограничения уровня поддержки рефакторинга всеми инструментами платформы разработки. Поэтому настоящая итеративная разработка обходится очень дорого и работу над моделью нужно вести постадийно.
Важно понимать, что в ходе процесса детализации должны возникать некоторые разногласия, результатом которых и является разделение обработки на несколько стадий. Постадийная разработка – это не просто следствие трудности обмена моделями между инструментами. Она отражает необходимость согласования изменений между членами команды разработки, прежде чем каждый из сотрудников перейдет к детализации своей части решения. Внесение изменений в проектные решения всегда оказывает влияние более обширное, чем можно предположить. Следовательно, влияние изменений следует оценить до утверждения проекта. В задачу менеджера проекта, бизнес-аналитика и ИТ-архитекторов входит притормаживание появляющихся в ходе детализации предлагаемых изменений, которые могут повлиять на требования и архитектуру и в конечном счете повредить другим частям реализации. Выгода от возможности безболезненного обмена моделями между инструментами состоит не в том, чтобы устранить необходимость деления разработки на стадии, а в том, чтобы реализация согласованных изменений обходилась дешевле.
Мы выбрали подход, в котором бизнес-аналитик документирует бизнес-процесс с помощью WebSphere Business Integration Modeler и рассматривает модель как спецификацию для программирования. Архитектор и ИТ-специалисты могли произвольно использовать, дополнять и изменять модель в соответствии с целями реализации. Модель не является жестким и стабильным описанием работы процесса.
Мы рассматриваем созданную аналитиком модель бизнес-процесса как определение того, что представляет собой процесс, а не как спецификацию реальной работы процесса. На какой-то стадии бизнес-аналитик должен изучить ИТ-модель и утвердить ее как обоснованную реализацию бизнес-модели. Это напоминает традиционный подход к разработке программ, и все же это один из способов разработки, управляемой моделями.
На рис. 3.6 иллюстрируется три разных способа понимания взаимосвязи между бизнес-моделью и ИТ-моделью.
(рис 3.6) Разные подходы к реализации бизнес-моделиЭто почти зрелая модель технологии моделирования автоматизированных бизнес-процессов. Пункт (А) соответствует обычно используемым графическим технологиям, от рисунков на клочках бумаги к Visio и к организованным инструментам моделирования бизнес-процессов, таким, как WebSphere Business Integration Modeler. Пункт (В) соответствует существующим инструментам, основанным на исполняемых языках процессов, таких, как BPEL, и отражает собой современный уровень технологии. Пункт (С), возможно, отражает путь, по которому технология пойдет дальше.
Мы идентифицировали три главные фазы разработки архитектуры на основе детализации
модели решения (рис. 3.7). Это дало нам три контракта. Первая фаза рассматривается
в лекции 4, "Бизнес-процесс", и представляет собой разработку модели бизнес-процесса.
Такая бизнес-модель называется "моделью, независимой от вычислений"
(Computationally Independent Model,
(рис 3.7) Контракты между ролями, задействованными в реализации процессаРазработка архитектуры описывается в лекции 5, "Архитектура системы", и в лекции 6,
"Архитектура решения". Показывается, как архитектор решения включает бизнес-модель,
созданную в WebSphere Business Integration Modeler, в платформо-независимую
модель (
Модель
Архитектор с помощью ИT-специалистов и архитектора инфраструктуры
переводит
Семинары по моделированию, в которых участвуют люди, выполняющие роли, связанные с бизнесом и ИТ, – это чрезвычайно эффективный способ определения требований. Поскольку не бывает правильных ответов на вопросы процесса и архитектуры (хотя бывают неправильные!), обсуждение применения процессов и шаблонных моделей очень полезно для выработки общего понимания требований и предлагаемого решения.
Еще одно преимущество подхода с использованием семинаров состоит в том, что
такой подход играет важную роль объединении всей команды, задействованной в руководстве
проектом, в создании решения и в конечном счете в его применении. При этом
создается работоспособное решение, и используются выгоды, которое оно дает. Существует
ряд опасностей, возникающих, когда проблемы программных инженеров приобретают
слишком большой вес при построении решения, и это хорошо описано в работе
Алана Купера (Alan Cooper)
Чтобы такое участие было эффективным, оно должно быть организовано и должно
приниматься всеми представителями заинтересованных сторон. Существует ряд
книг, специально посвященных переработке бизнес-процессов, в которых уделяется
внимание сбору информации о существующем бизнес-процессе и выполнению задачи
по его совершенствованию. Можно начать с книги серии Redbooks под названием
"Continuous business
В этой книге описывается один из методов разработки бизнес-процессов, специально ориентированный на платформу WebSphere версии 4.
Разработка нового бизнес-процесса и его автоматизация – это лишь часть общей
задачи по перестройке бизнеса. Разработка нового бизнес-процесса должна быть
частью более обширной задачи реализации изменения. Модель процесса – это эффективный
способ организации обсуждения бизнес-процесса с руководителями
и пользователями
Создание высокоуровневой архитектуры начинается с самых ранних стадий проектирования решения. Как показано в модели на рис. 3.8, спецификации архитектуры со временем переходят от исходных, самых высокоуровневых концептуальных представлений к детальным, специфическим представлениям физического уровня. Стадии, через которые мы проходили, пронумерованы цифрами от 1 до 4.
(рис 3.8) Использование шаблонов и активов в жизненном циклеЗначительная часть проектирования архитектуры выполняется с помощью много-уровневой модели активов Patterns for e-business.
Шаблоны для электронного бизнеса (Patterns for e-business) позволяют архитекторам создавать успешно работающие решения для электронного бизнеса на основе повторного использования компонентов и элементов из зарекомендовавших себя решений. Данный подход основывается на наборе многоуровневых активов, который может применять любая существующая методология разработки. Эти активы организованы так, что каждый следующий уровень детализации строится на основе предыдущего. Эти активы включают в себя:
Эти активы и их взаимосвязи друг с другом показаны на рис. 3.9.
(рис 3.9) Многоуровневая модель активов Patterns for e-businessWeb-сайт Patterns for e-business предоставляет простой способ навигации по многоуровневой модели активов с целью определения активов, наиболее подходящих для конкретной ситуации.
За справками обращайтесь на сайт Patterns for e-business: http://www.ibm.com/developerWorks/patterns/
Подход, который мы используем в главе 5, "Архитектура системы", при разработке
решения для работы с внешними
(рис 3.10) Процесс выбора шаблонов Patterns for e-business и многоуровневая модель активовИспользуется многостадийная последовательность, где каждый шаг имеет цель, связанную с анализом конкретного набора ключевых требований, и имеет результат, связанный с выбором конкретных шаблонов из набора на основе этих требований. На каждом этапе создаются входные данные для следующего этапа, и в результате формируются направляющие ограничения, которые постепенно сужают процесс поиска, ограничивая его следующим рассматриваемым набором шаблонов. В конечном счете формируются топологии архитектурного уровня и связи с продуктами, являющиеся основой архитектуры решения.
Недавно был разработан метод на основе UML2 для применения процесса выбора шаблонов к шаблонам интеграции процессов.
На рис. 3.11 дается общий обзор подхода
Process Integration Design
(рис 3.11) Подход к разработке решений по интеграции процессовМы выбрали этот метод проектирования интеграции в силу ряда причин:
Когда мы в первый раз представляем себе будущую систему, мы подходим к ней с точки зрения ее желательного поведения. Желательное поведение системы является результатом кооперации нескольких компонентов, удовлетворяющих четко обозначенную потребность бизнеса. Поскольку мы подходим к системе от общего понимания ее бизнес-функции, мы не знаем детали кооперации компонентов и имеем только общее представление о типах нужных нам высокоуровневых взаимодействий.
Начиная с бизнес-уровня системы анализ представляет собой выявление необходимых взаимодействий и разложение их на составные части, чтобы лучше понять эти взаимодействия. В какой-то момент мы получим представление о кооперации и взаимодействиях компонентов, которое позволит нам определить, какие ИТ-компоненты нам нужны и как связать их с уже имеющимися готовыми реализациями.
В конечном счете наше знание компонентов и взаимодействий в будущей системе должно стать точным. Однако в начале анализа, когда мы не знаем всего подробно, и позже, когда нам нужно будет выбрать какую-то деталь, чтобы обсудить ее, нам необходимо иметь возможность контролировать уровень детализации, чтобы не возникало перегрузки деталями в ущерб общей картине. Решением будет рассмотрение системы как набора частей, которые можно просто представить на любом уровне детализации без риска сделать это неверно.
Это очень важное понятие, называемое фракталом. Оно позволяет нам моделировать и описывать системы должным образом на любом нужном уровне детализации. Например, мы можем показать кооперацию двух компонентов системы в виде простой линии, отражающей их взаимосвязь, или можем разделять эту линию на новые и новые компоненты и их взаимосвязи, которые все вместе представлены этой линией. Этот принцип проиллюстрирован на рис. 3.12.
(рис 3.12) Фрактальное разделение взаимодействияВажный момент состоит в том, что представление вверху не менее правильно, чем представление внизу. Оба они отражают одну и ту же модель, но по-разному. Можно представить себе UML-редактор, способный переключаться между такими представлениями.
Соответственно любая концепция, которую мы используем при поведенческом анализе таких систем, должна быть независимой от масштаба ; она должна работать независимо от того, обращаемся ли мы к очень большой системе или к любой из ее частей. Этот принцип лежит в основе описания архитектуры системы в модели, которую затем можно передать ИТ-специалистам для реализации, при полном сохранении той модели, которая была исходно создана архитектором.
Приведенные ниже концепции важны для понимания технологии Patterns for e-business.
| Кооперация (Collaboration) | Под кооперацией понимается выполнение любого набора вычислительных операций, распределенных в определенном пространстве (компьютерной сети) и времени. |
| Взаимодействие (Interaction) | Взаимодействие – это кооперация, являющаяся результатом одной операции или события. |
| Контекст (Context) | Данные (включая данные о состоянии, программы и правила выполнения), связанные с кооперацией, образуют контекст. |
| Качество обслуживания (Quality of Service) | Кооперация может подчиняться набору требований качества обслуживания (QoS), которые ограничивают ее выполнение. |
| Фрактал ( |
Кооперация является фракталом, если и разделение и объединение коопераций дают в результате кооперации. |
Заманчиво представлять себе разработку ИТ-системы, начинающуюся с нуля и двига-
ющуюся понятным путем через фазы анализа, проектирования и построения в один
проход или в несколько. Однако очень немногие ИТ-проекты представляют собой
пустые, спокойно выполняемые линейные проекты. Почти всегда существуют какие-то
готовые элементы (или даже целые системы), которые нужно изменить или просто
включить в новую систему. Это будет практически обязательным для интеграционных
проектов, которые по определению заставляют существующие системы работать
друг с другом, как правило, каким-то новым способом. Это относится и к решению
для работы с внешними
Следовательно, главной задачей создания архитектуры и проектирования интеграции процессов должно быть отслеживание разрастающихся различий между существующими и предполагающимися компонентами и конфигурациями.
Помощь в определении этих различий может оказать нотация, используемая в технологии Patterns for e-business, которая явно отображает существующие и новые компоненты решения, а также предлагает внешние контекстные элементы (например, такие, которые не принимают участие в работе системы, но могут взаимодействовать с ней, часто четко заданным способом).
Разница между функциональными и нефункциональными требованиями в ИТ-методологии осознается уже давно. Однако термин "нефункциональные" не слишком хорош, поскольку имеет негативный оттенок (он относится к тем требованиям, которые нельзя определить в виде конкретной бизнес-функции). Фактически нефункциональные требования часто в значительной мере определяют выбор конкретной рабочей среды и продуктов и влияют на топологию системы. Характерной особенностью этих требований является то, что они охватывают всю систему. Они обычно связываются с совокупными показателями, а не с какими-то конкретными взаимодействиями, их часто можно изменить в глобальных статистических показателях, и они отражают общее качество, а не бинарные свойства (да/нет). Поэтому вместо термина "нефункциональные свойства" появился термин "качество обслуживания".
Из-за своей очевидности такая характеристика QoS, как управление, часто недооценивается. Управление определяет, как система формируется из частей в различных областях внутри компании и за ее пределами. Управление оказывает существенное влияние на дизайн со многих точек зрения. Оно влияет не только на компонентизацию (система редко состоит из одного компонента, находящегося в общем пользовании разных областей), но также существенно влияет на выбор технологии, определяя, какие части можно менять вместе при выпуске новой версии решения и какие части должны существовать вместе в разных версиях.
Что касается функциональных требований, то они определяются прецедентами использования (Use Case) на уровне дизайна системы. Прецеденты использования описывают желательное поведение системы, которое выражается на уровне бизнеса через бизнес-сценарии и бизнес-процессы. В контексте интеграции процессов функциональное содержание в первую очередь выражается связями-взаимодействиями, которые, в свою очередь, определяют топологию системы. Так что мы можем назвать функциональные требования топологическими требованиями.
Итак, существует два типа требований к системе:
| топологические: | способ осуществления связей и взаимодействий между разными компонентами системы; |
| QoS: | определяются статистическими параметрами или как свойства совокупностей; эти свойства могут относиться к системе в целом, к конкретным компонентам или к конкретным сценариям. |
Все эти принципы были сведены вместе в описании набора
Мы не предполагаем, что
Данный метод включает в себя следующие задачи:
Не разделяя систему дальше, вы не можете узнать всего, что вам нужно знать на данном уровне абстракции. С другой стороны, некоторые вещи можно узнать заранее, что даст возможность отказаться от каких-то вариантов дизайна как от нереалистичных. Идеальным было бы найти равновесие между сохранением в открытом состоянии разных вариантов дизайна без фиксации на конкретном решении и глубоким погружением в анализ и проектирование без учета реально имеющихся возможностей. Длительное игнорирование требований качества обслуживания может поставить анализ и проектирование в ситуацию невозможности обеспечения необходимого качества.
Такая проверка на реалистичность должна также присутствовать для того, чтобы принимать во внимание существующие компоненты ("черные ящики"). Еще одним граничным условием является учет доступных для нас продуктов. Не откладывайте на самый конец анализа проверку того, можно ли объединить в целое изученные вами кооперации.
Короче говоря, фрактальное мышление стимулирует нас принимать во внимание все аспекты на всех уровнях анализа сразу.
Мы не предполагаем, что данный процесс будет полностью итеративным или выполняемым в несколько проходов. Архитектор должен находить правильные точки для передачи информации для дальнейшей детализации, чтобы не приходилось возвращаться к архитектурным решениям при реализации. Именно по этой причине физическая реализация архитектуры в виде выбора конкретных продуктов выполняется на как можно более ранней стадии, задолго до того, как формируется подробный дизайн. Такой поход отличается от традиционного подхода, используемого в методах OOAD. Архитектор должен принимать во внимание фактор достижимости при реализации, чтобы свести к минимуму пересмотр архитектурных решений.
Цель состоит в том, чтобы максимально отдалить принятие конкретных решений по дизайну. Принимайте эти решения только в следующих случаях:
Решения принимаются на том уровне анализа, на котором они могут быть полностью оправданы. Этими уровнями могут быть:
Метод с проведением семинаров и разработкой по контракту вполне поддерживает применение данного подхода.
Использование средств моделирования и работы с метаданными для продвижения
по стадиям архитектурной детализации и для управления сложностью разработки
программного обеспечения являются одним из аспектов разработки, управляемой
моделями
MDD – это подход, при котором:
MDD предлагает подход, при котором бизнес-аналитик может зафиксировать биз-
нес-процессы в модели, независимой от вычислений (Computation Independent Model,
(рис 3.13) Архитектура, управляемая моделямиЧтобы инструменты могли обмениваться программными артефактами и размещать код и другие артефакты, такие, как спецификации конфигураций, на рабочих платформах, необходимы стандарты моделирования и работы с метаданными.
Артефакты, создаваемые на каждом этапе, должны быть определены командой разработки с использованием модели процесса, например Rational Unified Process (RUP). Хотя в данном курсе основное внимание уделяется области разработки, не менее важны и другие области – тестирование, удобство использования и управления системой, а также вопрос внедрения решения в пользовательское сообщество. Должно ли решение продаваться, предлагаться как часть обслуживания или как часть специальной разработки в пределах конкретного предприятия? Люди, работающие над этими аспектами, должны постоянно участвовать в процессе разработки, чтобы разработка, тестирование и удобство использования находились в связи с наиболее важными аспектами решения.
Основные преимущества, которые дает тщательное следование подходу MDD, следующие:
MDD снижает стоимость разработки программного обеспечения с помощью генерации кода и артефактов по моделям, что повышает производительность труда разработчика.
При добавлении новой бизнес-функции вам нужно только разработать поведение, относящееся к этой новой функции. Вся остальная информация, необходимая для генерации артефактов реализации, уже заключена в трансформациях.
MDD способствует тому, чтобы артефакты генерировались согласованно.
Подход MDD особенно хорош, если его применять на уровне программы или организации. Использование опробованных и протестированных трансформаций повышает предсказуемость при разработке новых функций и уменьшает риск, поскольку архитектурные и технические проблемы были уже разрешены.
Модели гораздо ближе к предметной области проблемы, и их гораздо проще донести. Совершенствование процесса коммуникации способствует созданию решений, лучше соответствующих целям бизнеса.
Модели облегчают понимание и обоснования системы на уровне дизайна. Тот факт, что модели являются частью определения системы, а не частью документации, означает, что модели никогда не будут устаревшими или недостоверными.
В моделях фиксируется опыт. Явное сохранение опыта обеспечивает сохранение знаний, даже если эксперты покинут организацию.
В MDD модели – это важное достояние, в которых фиксируется то, что делают ИТ-системы организации. Высокоуровневые модели устойчивы к изменениям, связанным с совершенствованием платформенного уровня. Они изменяются только тогда, когда изменяются бизнес-требования.
При использовании MDD ранняя стадия разработки приложения в основном
касается моделирования. Это означает, что существует возможность отсрочить
выбор конкретной
В создаваемом нами решении мы лишь слегка касаемся преимуществ, которые может дать MDD. Однако опыт, который компания LGI приобретает при использовании средств моделирования для описания решения, – это первый шаг в процессе повышения зрелости используемого подхода, что даст существенные выгоды в будущем.
Разработка, управляемая моделями? – это подход к разработке, при котором главными
артефактами являются модели (а не программы). Модели могут поэтапно трансформироваться,
пока не будет создан базовый код. На рис. 3.14 показан пример
трансформации
(рис 3.14) Трансформация моделейЧтобы трансформировать нашу бизнес-проблему в решение, использующее разработку, управляемую моделями, мы будем применять различные инструменты. Мы должны понять, какой тип инструментов необходимо использовать для каждой роли в разработке, а затем должны понять, как модель будет передаваться от инструмента к инструменту и какие ограничения накладывает передача артефактов от одного инструмента к другому.
Идеалом является создание двунаправленной
В настоящее время имеющаяся цепочка инструментов поддерживает только
однонаправленный (или каскадный) подход к MDD. Обращение модели процесса –
дело будущего. Так что при принятии решения о том, как использовать эти инструменты,
важно принимать во внимание, что после того, как модель была экспортирована
из одного инструмента в другой, внесение изменений в вышестоящий инструмент
будет требовать больше времени и средств. Изменения, внесенные в вышестоящий
инструмент, также должны вручную быть переработаны в нижестоящих
Это одна из причин, по которым вас следует четко понимать области ответственности
и
На рис. 3.15 показана цепочка инструментов, на которой мы основывали нашу разработку. Бизнес-процесс фиксируется в инструменте для бизнес-моделирования бизнес-аналитиками. Эта модель используется двумя способами (см. пункт А на рис. 3.15). Она применяется для генерации определений процессов для оркестровки рабочих потоков, а также для моделирования архитектуры решения. Модель архитектуры решения содержит шаблоны, интерфейсы, модель размещения и схемы последовательностей. В оркестровке рабочих потоков процесс и архитектура рабочих потоков объединяются с последовательностью, потоками и выбранными сообщениями. Архитектурные модели и оркестровка рабочих потоков используются инструментами создания кода. На рис. 3.16 показана цепочка инструментов, которую мы применяли в этом курсе.
(рис 3.16) Цепочка инструментов(рис 3.15) Цепочка инструментов, использованная в данном курсеИспользуемая нами цепочка инструментов не имеет возможности для автоматического
включения в модель шаблонов Patterns for e-business. Мы применили инструменты
с Web-сайта Patterns for e-business для выбора шаблонов, которые потом перенесли
в Microsoft Visio. После того как мы согласовали шаблоны, мы перенесли получившуюся
схему размещения в Rational
Ниже приводится суммарный список использованных нами инструментов.
На основе входных данных, полученных из WebSphere Business Integration Modeler
и интерфейсов имеющихся реализаций, Rational
Главные артефакты, которыми архитекторы обмениваются с инструментами ИТ-специалистов,
является код BPEL, FDL и
В этой лекции описан подход, который мы применяли при разработке и интеграции
нового процесса работы с внешними
Выполнить проект, связанный с интеграцией так, чтобы все были удовлетворены, оказывается сложнее, чем выполнить проект по разработке с нуля. Главная причина этого – трудности общения между людьми, представляющими различные аспекты решения, которые с самого начала проекта борются друг с другом за внимание к своим целям. Метод, который мы описали в этой лекции и которому следуем, позволяет усовершенствовать общение между разными ролями, задействованными в проекте, акцентируя внимание на том, что нужно сделать для удовлетворения требований, представленных в бизнес-процессе. При этом используется общая платформа, упрощающая обмен артефактами в решениях, и общие языки моделирования, обеспечивающие взаимозаменяемость артефактов. В лекции 4, "Бизнес-процесс", мы начинаем рассматривать моделирование бизнес-требований.
Одной из наших целей, обозначенных в разделе 1.3, "Цели и ограничения,
связанные с информационными технологиями", является повышение производительности
разработки при использовании современных инструментов
и технологий. Новая система реализует
В этой лекции мы опишем метод, который мы используем при создании
решения для работы с внешними
Что такое бизнес по требованию (On Demand Business)? IBM определяет его как бизнес, руководители которого могут видеть свою компанию и управлять ею как единым целым. Это означает, что все отрасли бизнеса должны задействовать друг друга в ходе динамических преобразований ранее изолированных операций, проводимых отдельными подразделениями, в цельный интегрированный бизнес-процесс, охватывающий всю компанию, а также клиентов за ее пределами.
Бизнес по требованию имеет четыре наиболее существенные характеристики:
За дополнительной информацией о бизнесе по требованию обращайтесь на сайт http://www-306.ibm.com/e-business/ondemand/us/overview/overview.shtml
Компания LGI преобразует себя в бизнес по требованию следующим образом:
Преобразуя свою ИТ-инфраструктуру в инфраструктуру на основе открытых стандартов, что делает LGI более гибкой и готовой к ответу на изменение нужд бизнеса.
При разработке решений акцент делается на новых или более эффективных бизнес-процессах, включающих в себя клиентов, подразделения и поставщиков.
Формирование разработки программного обеспечения является стратегическим бизнес-процессом, который определяет успех бизнеса и который должен направляться горизонтальной интеграцией того же типа, что и другие бизнес-процессы.
Операционная среда, работающая по требованию, имеет две цели – упрощение
работы с ИТ и повышение гибкости бизнеса. Она представляет собой набор средств
управления интеграцией и инфраструктурой, который на модульной и инкрементной
основе может использоваться клиентами и партнерами для обеспечения перехода
к бизнесу по требованию. Эта среда состоит из двух частей – управление инфра-структурой
и управление интеграцией, которые решают задачи упрощения работы
с ИТ и повышения гибкости бизнеса. Обращайтесь к книге серии IBM Redbook под
названием "On Demand
Управление инфраструктурой – это создание консолидированного логического
представления о ресурсах сети, а также обеспечение доступа к этому представлению.
Интеграция – это такое соединение людей, процессов и информации, которое позволяет
компаниям более гибко отвечать на динамические изменения рынков, клиентского
и
(рис 3.1) Операционная среда по требованиюВ решении для работы с внешними
Интерес к сервис-ориентированному моделированию возрастает в связи с пониманием
того, что существующие процессы разработки и нотации, такие, как объектно-ориентированный
анализ и проектирование (
Место, которое занимают OOAD, EA и
(рис 3.2) Позиционирование BPM, EA и OOAD (Zimmerman et al., Service-Oriented Analysis and Design)Этими методами занимаются разные люди. EA – это сфера деятельности
архитекторов предприятия, решений и инфраструктуры;
Идея упомянутых авторов состоит в том, что каждый из процессов, OOAD, EA
и
В разделе 3.1.3, "Платформа разработки программного обеспечения от IBM", описывается стратегия, лежащая в основе платформы разработки от IBM, ориентированная на интеграцию различных ролей и операций, задействованных в разработке программного решения.
IBM рассматривает разработку программного обеспечения как стратегический
бизнес-процесс. Разработка выигрывает от горизонтальной интеграции как любой
другой бизнес-процесс. IBM основывает свои инструменты разработки программного
обеспечения на общей платформе разработки (software
(рис 3.3) Разработка программного обеспечения: стратегический бизнес-процессПлатформа разработки программного обеспечения от IBM предлагает более широкий инструментарий для операционной среды по требованию, чем отдельные методологии разработки программного обеспечения. Данная платформа позволяет интегрировать разные подразделения, процессы и конечные продукты, задействованные в разработке программ, а также интегрирует конкретные инструменты.
Платформа разработки программного обеспечения от IBM преследует следующие цели:
Моделирование бизнес-процессов, моделирование информации и Rational Unified Process $$\text{\textregistered}$$ являются основными средствами соединения нужд бизнеса с ИТ-решениями.
Мы уделим основное внимание использованию моделирования бизнес-процессов
для соединения нужд бизнеса с ИТ-решением в сценарии работы с внешними
Программная платформа Eclipse в сочетании с каркасом Eclipse Modeling Framework
(
(рис 3.4) Платформа разработки программного обеспечения (Alan Brown в упомянутой работе)Инструменты, разработанные на основе нужд исполнителей конкретных ролей,
но с интеграцией на общей инструментальной платформе позволяют осуществлять
совместное использование артефактов с применением общей
Все используемые нами инструменты работают на платформе Eclipse и имеют общие характеристики. В частности, мы сконцентрируемся на следующих интеграционных задачах:
Rational Unified Process (RUP $$\text{\texttrademark}$$ ) – это основной инструмент, обеспечивающий полную видимость, снижение затрат и управление рисками в ходе разработки программного обеспечения.
В данном проекте мы не использовали RUP для определения процесса разработки
и управления им,
Подход, который использовался группой System
Этот метод описывается в следующих разделах:
Разработка решения для взаимодействия с внешними
В разработке участвуют следующие роли:
Роль бизнес-куратора состоит в том, чтобы задавать общие цели проекта работы
с внешними
Куратор будет лишь ограниченно привлекаться к повседневной разработке. Он будет использовать графические изображения бизнес-процесса и отчеты инструмента Modeler для создания презентаций с целью формулирования экономического обоснования и разъяснения предлагаемых изменений процесса для руководителей остальных отделов компании.
Один или несколько представителей от сообщества пользователей, в частности
Представители пользователей будут применять создаваемые графики для создания презентаций с целью разъяснения и обсуждения изменений со своими коллегами.
Менеджер проекта отвечает за выпуск решения для работы с внешними
Менеджер проекта будет сотрудничать с бизнес-аналитиком и использовать отчеты инструмента Modeler для формирования задач и областей ответственности.
Эта роль отвечает за проведение семинаров. Ее может выполнять менеджер проекта, бизнес-аналитик или специалист по процессам или кто-то, имеющий специальный опыт проведения семинаров. Важный момент состоит в том, что этот человек отвечает за проведение семинаров и за документирование их результатов.
Ответственный за документирование семинаров будет использовать WebSphere Business Integration Modeler или Microsoft Visio $$\text{\textregistered}$$ для записи моделей процесса. Продвижение в создании модели процесса может записываться после каждого семинара. В качестве альтернативы, если это удовлетворит всех участников, более эффективной будет интерактивная работа с инструментом с использованием проектора или же общего экрана (при дистанционном семинаре).
Бизнес-аналитик отвечает за бизнес-процессы, существующие в страховой
компании LGI. Аналитик отвечает перед бизнес-куратором за достижение целей,
поставленных для процесса автоматизации работы с
Бизнес-аналитик выполняет следующие задачи:
Бизнес-аналитик будет использовать WebSphere Business Integration Modeler. Он также будет использовать инструмент для создания и документирования процесса, определения измеряемых параметров, относящихся к целям, установленным для решения, и для эмуляции бизнес-процесса с целью проверки достижения поставленных целей.
ИТ-архитектор решения отвечает за связь нового процесса работы с внешними
Архитектор решения выполняет следующие задачи:
Главный инструмент, который должен применять архитектор решения, – это
Rational
Главной областью ответственности архитектора предприятия является определение стандартов для ИТ-инфраструктуры и стратегических ИТ-целей для бизнеса. Архитектор инфраструктуры отвечает за понимание стандартов и целей ИТ-инфраструктуры и за обеспечения соответствия новых решений этим стандартам и целям. Кроме этого, данный архитектор отвечает (хотя это и не входит в наш сценарий) за планирование пропускной способности, выполнение требований по времени ответа и уровню обслуживания, за обслуживание ИТ-инфраструктуры, отказоустойчивость, а также за резервное копирование и восстановление системы.
Архитектор данных отвечает за моделирование корпоративных данных, за определение таблиц баз данных и связей между ними. Он должен иметь глубокое понимание бизнеса, а также технические знания в области реляционных моделей данных.
В этом тексте мы опустили все вопросы, связанные с моделями данных, поскольку основное внимание мы уделяем интеграции на основе процессов. Когда нам нужно будет выбрать инструменты для моделирования и построения решения, вопросам, связанным с данными, будет уделено самое пристальное внимание.
В данном сценарии мы опускаем все вопросы, связанные с безопасностью, защитой личных данных и с соответствием законам о защите информации и другим законодательным актам.
ИТ-архитектор может обращаться к ИТ-специалистам на ранних стадиях разработки с целью выяснения того, как работает существующая система. Если специалисты будут присутствовать на ранних семинарах по проектированию процесса, это будет полезно, поскольку они будут уточнять дизайн. Специалисты смогут проверить, имеет ли модель процесса достаточную детализацию, чтобы с ней можно было работать.
Главной областью ответственности ИТ-специалистов является экспортирование
модели процесса, созданной бизнес-аналитиком (BPEL), из WebSphere Business
Integration Modeler, модели, созданной ИТ-архитектором (UML), из Rational Software
(рис 3.5) Роли, участвующие в создании решенияРазработчики приложений выполняют следующие задачи:
У нас было четыре ИТ-специалиста. Мы объединили роли, связанные с разработкой и обслуживанием рабочей системы, поскольку основное внимание мы уделяем разработке, а единственная задача, относящаяся у нас к рабочей системе, – это ее размещение:
Специалист по
Главным инструментом этого специалиста является
Этот специалист отвечает за базовую инфраструктуру
Этот специалист отвечает за реализацию нового BPEL-процесса работы с
внешними
Специалист по WebSphere Application Server отвечает за создание
и размещение служб, используемых для автоматизации обработки претензий.
Мы употребили для создания служб WebSphere Studio
В нашем методе все эти многочисленные роли работают вместе на каждой стадии
разработки. В ходе разработки создаются промежуточные продукты, такие, как модель
бизнес-процесса и документ архитектуры решения. Эти документы формируют
контракты между членами команды и являются маркерами продвижения проекта
в целом. Такой процесс не является в строгом смысле
Как говорится в разделе 3.2.8, "Цепочки инструментов", сегодня существуют ограничения уровня поддержки рефакторинга всеми инструментами платформы разработки. Поэтому настоящая итеративная разработка обходится очень дорого и работу над моделью нужно вести постадийно.
Важно понимать, что в ходе процесса детализации должны возникать некоторые разногласия, результатом которых и является разделение обработки на несколько стадий. Постадийная разработка – это не просто следствие трудности обмена моделями между инструментами. Она отражает необходимость согласования изменений между членами команды разработки, прежде чем каждый из сотрудников перейдет к детализации своей части решения. Внесение изменений в проектные решения всегда оказывает влияние более обширное, чем можно предположить. Следовательно, влияние изменений следует оценить до утверждения проекта. В задачу менеджера проекта, бизнес-аналитика и ИТ-архитекторов входит притормаживание появляющихся в ходе детализации предлагаемых изменений, которые могут повлиять на требования и архитектуру и в конечном счете повредить другим частям реализации. Выгода от возможности безболезненного обмена моделями между инструментами состоит не в том, чтобы устранить необходимость деления разработки на стадии, а в том, чтобы реализация согласованных изменений обходилась дешевле.
Мы выбрали подход, в котором бизнес-аналитик документирует бизнес-процесс с помощью WebSphere Business Integration Modeler и рассматривает модель как спецификацию для программирования. Архитектор и ИТ-специалисты могли произвольно использовать, дополнять и изменять модель в соответствии с целями реализации. Модель не является жестким и стабильным описанием работы процесса.
Мы рассматриваем созданную аналитиком модель бизнес-процесса как определение того, что представляет собой процесс, а не как спецификацию реальной работы процесса. На какой-то стадии бизнес-аналитик должен изучить ИТ-модель и утвердить ее как обоснованную реализацию бизнес-модели. Это напоминает традиционный подход к разработке программ, и все же это один из способов разработки, управляемой моделями.
На рис. 3.6 иллюстрируется три разных способа понимания взаимосвязи между бизнес-моделью и ИТ-моделью.
(рис 3.6) Разные подходы к реализации бизнес-моделиЭто почти зрелая модель технологии моделирования автоматизированных бизнес-процессов. Пункт (А) соответствует обычно используемым графическим технологиям, от рисунков на клочках бумаги к Visio и к организованным инструментам моделирования бизнес-процессов, таким, как WebSphere Business Integration Modeler. Пункт (В) соответствует существующим инструментам, основанным на исполняемых языках процессов, таких, как BPEL, и отражает собой современный уровень технологии. Пункт (С), возможно, отражает путь, по которому технология пойдет дальше.
Мы идентифицировали три главные фазы разработки архитектуры на основе детализации
модели решения (рис. 3.7). Это дало нам три контракта. Первая фаза рассматривается
в лекции 4, "Бизнес-процесс", и представляет собой разработку модели бизнес-процесса.
Такая бизнес-модель называется "моделью, независимой от вычислений"
(Computationally Independent Model,
(рис 3.7) Контракты между ролями, задействованными в реализации процессаРазработка архитектуры описывается в лекции 5, "Архитектура системы", и в лекции 6,
"Архитектура решения". Показывается, как архитектор решения включает бизнес-модель,
созданную в WebSphere Business Integration Modeler, в платформо-независимую
модель (
Модель
Архитектор с помощью ИT-специалистов и архитектора инфраструктуры
переводит
Семинары по моделированию, в которых участвуют люди, выполняющие роли, связанные с бизнесом и ИТ, – это чрезвычайно эффективный способ определения требований. Поскольку не бывает правильных ответов на вопросы процесса и архитектуры (хотя бывают неправильные!), обсуждение применения процессов и шаблонных моделей очень полезно для выработки общего понимания требований и предлагаемого решения.
Еще одно преимущество подхода с использованием семинаров состоит в том, что
такой подход играет важную роль объединении всей команды, задействованной в руководстве
проектом, в создании решения и в конечном счете в его применении. При этом
создается работоспособное решение, и используются выгоды, которое оно дает. Существует
ряд опасностей, возникающих, когда проблемы программных инженеров приобретают
слишком большой вес при построении решения, и это хорошо описано в работе
Алана Купера (Alan Cooper)
Чтобы такое участие было эффективным, оно должно быть организовано и должно
приниматься всеми представителями заинтересованных сторон. Существует ряд
книг, специально посвященных переработке бизнес-процессов, в которых уделяется
внимание сбору информации о существующем бизнес-процессе и выполнению задачи
по его совершенствованию. Можно начать с книги серии Redbooks под названием
"Continuous business
В этой книге описывается один из методов разработки бизнес-процессов, специально ориентированный на платформу WebSphere версии 4.
Разработка нового бизнес-процесса и его автоматизация – это лишь часть общей
задачи по перестройке бизнеса. Разработка нового бизнес-процесса должна быть
частью более обширной задачи реализации изменения. Модель процесса – это эффективный
способ организации обсуждения бизнес-процесса с руководителями
и пользователями
Создание высокоуровневой архитектуры начинается с самых ранних стадий проектирования решения. Как показано в модели на рис. 3.8, спецификации архитектуры со временем переходят от исходных, самых высокоуровневых концептуальных представлений к детальным, специфическим представлениям физического уровня. Стадии, через которые мы проходили, пронумерованы цифрами от 1 до 4.
(рис 3.8) Использование шаблонов и активов в жизненном циклеЗначительная часть проектирования архитектуры выполняется с помощью много-уровневой модели активов Patterns for e-business.
Шаблоны для электронного бизнеса (Patterns for e-business) позволяют архитекторам создавать успешно работающие решения для электронного бизнеса на основе повторного использования компонентов и элементов из зарекомендовавших себя решений. Данный подход основывается на наборе многоуровневых активов, который может применять любая существующая методология разработки. Эти активы организованы так, что каждый следующий уровень детализации строится на основе предыдущего. Эти активы включают в себя:
Эти активы и их взаимосвязи друг с другом показаны на рис. 3.9.
(рис 3.9) Многоуровневая модель активов Patterns for e-businessWeb-сайт Patterns for e-business предоставляет простой способ навигации по многоуровневой модели активов с целью определения активов, наиболее подходящих для конкретной ситуации.
За справками обращайтесь на сайт Patterns for e-business: http://www.ibm.com/developerWorks/patterns/
Подход, который мы используем в главе 5, "Архитектура системы", при разработке
решения для работы с внешними
(рис 3.10) Процесс выбора шаблонов Patterns for e-business и многоуровневая модель активовИспользуется многостадийная последовательность, где каждый шаг имеет цель, связанную с анализом конкретного набора ключевых требований, и имеет результат, связанный с выбором конкретных шаблонов из набора на основе этих требований. На каждом этапе создаются входные данные для следующего этапа, и в результате формируются направляющие ограничения, которые постепенно сужают процесс поиска, ограничивая его следующим рассматриваемым набором шаблонов. В конечном счете формируются топологии архитектурного уровня и связи с продуктами, являющиеся основой архитектуры решения.
Недавно был разработан метод на основе UML2 для применения процесса выбора шаблонов к шаблонам интеграции процессов.
На рис. 3.11 дается общий обзор подхода
Process Integration Design
(рис 3.11) Подход к разработке решений по интеграции процессовМы выбрали этот метод проектирования интеграции в силу ряда причин:
Когда мы в первый раз представляем себе будущую систему, мы подходим к ней с точки зрения ее желательного поведения. Желательное поведение системы является результатом кооперации нескольких компонентов, удовлетворяющих четко обозначенную потребность бизнеса. Поскольку мы подходим к системе от общего понимания ее бизнес-функции, мы не знаем детали кооперации компонентов и имеем только общее представление о типах нужных нам высокоуровневых взаимодействий.
Начиная с бизнес-уровня системы анализ представляет собой выявление необходимых взаимодействий и разложение их на составные части, чтобы лучше понять эти взаимодействия. В какой-то момент мы получим представление о кооперации и взаимодействиях компонентов, которое позволит нам определить, какие ИТ-компоненты нам нужны и как связать их с уже имеющимися готовыми реализациями.
В конечном счете наше знание компонентов и взаимодействий в будущей системе должно стать точным. Однако в начале анализа, когда мы не знаем всего подробно, и позже, когда нам нужно будет выбрать какую-то деталь, чтобы обсудить ее, нам необходимо иметь возможность контролировать уровень детализации, чтобы не возникало перегрузки деталями в ущерб общей картине. Решением будет рассмотрение системы как набора частей, которые можно просто представить на любом уровне детализации без риска сделать это неверно.
Это очень важное понятие, называемое фракталом. Оно позволяет нам моделировать и описывать системы должным образом на любом нужном уровне детализации. Например, мы можем показать кооперацию двух компонентов системы в виде простой линии, отражающей их взаимосвязь, или можем разделять эту линию на новые и новые компоненты и их взаимосвязи, которые все вместе представлены этой линией. Этот принцип проиллюстрирован на рис. 3.12.
(рис 3.12) Фрактальное разделение взаимодействияВажный момент состоит в том, что представление вверху не менее правильно, чем представление внизу. Оба они отражают одну и ту же модель, но по-разному. Можно представить себе UML-редактор, способный переключаться между такими представлениями.
Соответственно любая концепция, которую мы используем при поведенческом анализе таких систем, должна быть независимой от масштаба ; она должна работать независимо от того, обращаемся ли мы к очень большой системе или к любой из ее частей. Этот принцип лежит в основе описания архитектуры системы в модели, которую затем можно передать ИТ-специалистам для реализации, при полном сохранении той модели, которая была исходно создана архитектором.
Приведенные ниже концепции важны для понимания технологии Patterns for e-business.
| Кооперация (Collaboration) | Под кооперацией понимается выполнение любого набора вычислительных операций, распределенных в определенном пространстве (компьютерной сети) и времени. |
| Взаимодействие (Interaction) | Взаимодействие – это кооперация, являющаяся результатом одной операции или события. |
| Контекст (Context) | Данные (включая данные о состоянии, программы и правила выполнения), связанные с кооперацией, образуют контекст. |
| Качество обслуживания (Quality of Service) | Кооперация может подчиняться набору требований качества обслуживания (QoS), которые ограничивают ее выполнение. |
| Фрактал ( |
Кооперация является фракталом, если и разделение и объединение коопераций дают в результате кооперации. |
Заманчиво представлять себе разработку ИТ-системы, начинающуюся с нуля и двига-
ющуюся понятным путем через фазы анализа, проектирования и построения в один
проход или в несколько. Однако очень немногие ИТ-проекты представляют собой
пустые, спокойно выполняемые линейные проекты. Почти всегда существуют какие-то
готовые элементы (или даже целые системы), которые нужно изменить или просто
включить в новую систему. Это будет практически обязательным для интеграционных
проектов, которые по определению заставляют существующие системы работать
друг с другом, как правило, каким-то новым способом. Это относится и к решению
для работы с внешними
Следовательно, главной задачей создания архитектуры и проектирования интеграции процессов должно быть отслеживание разрастающихся различий между существующими и предполагающимися компонентами и конфигурациями.
Помощь в определении этих различий может оказать нотация, используемая в технологии Patterns for e-business, которая явно отображает существующие и новые компоненты решения, а также предлагает внешние контекстные элементы (например, такие, которые не принимают участие в работе системы, но могут взаимодействовать с ней, часто четко заданным способом).
Разница между функциональными и нефункциональными требованиями в ИТ-методологии осознается уже давно. Однако термин "нефункциональные" не слишком хорош, поскольку имеет негативный оттенок (он относится к тем требованиям, которые нельзя определить в виде конкретной бизнес-функции). Фактически нефункциональные требования часто в значительной мере определяют выбор конкретной рабочей среды и продуктов и влияют на топологию системы. Характерной особенностью этих требований является то, что они охватывают всю систему. Они обычно связываются с совокупными показателями, а не с какими-то конкретными взаимодействиями, их часто можно изменить в глобальных статистических показателях, и они отражают общее качество, а не бинарные свойства (да/нет). Поэтому вместо термина "нефункциональные свойства" появился термин "качество обслуживания".
Из-за своей очевидности такая характеристика QoS, как управление, часто недооценивается. Управление определяет, как система формируется из частей в различных областях внутри компании и за ее пределами. Управление оказывает существенное влияние на дизайн со многих точек зрения. Оно влияет не только на компонентизацию (система редко состоит из одного компонента, находящегося в общем пользовании разных областей), но также существенно влияет на выбор технологии, определяя, какие части можно менять вместе при выпуске новой версии решения и какие части должны существовать вместе в разных версиях.
Что касается функциональных требований, то они определяются прецедентами использования (Use Case) на уровне дизайна системы. Прецеденты использования описывают желательное поведение системы, которое выражается на уровне бизнеса через бизнес-сценарии и бизнес-процессы. В контексте интеграции процессов функциональное содержание в первую очередь выражается связями-взаимодействиями, которые, в свою очередь, определяют топологию системы. Так что мы можем назвать функциональные требования топологическими требованиями.
Итак, существует два типа требований к системе:
| топологические: | способ осуществления связей и взаимодействий между разными компонентами системы; |
| QoS: | определяются статистическими параметрами или как свойства совокупностей; эти свойства могут относиться к системе в целом, к конкретным компонентам или к конкретным сценариям. |
Все эти принципы были сведены вместе в описании набора
Мы не предполагаем, что
Данный метод включает в себя следующие задачи:
Не разделяя систему дальше, вы не можете узнать всего, что вам нужно знать на данном уровне абстракции. С другой стороны, некоторые вещи можно узнать заранее, что даст возможность отказаться от каких-то вариантов дизайна как от нереалистичных. Идеальным было бы найти равновесие между сохранением в открытом состоянии разных вариантов дизайна без фиксации на конкретном решении и глубоким погружением в анализ и проектирование без учета реально имеющихся возможностей. Длительное игнорирование требований качества обслуживания может поставить анализ и проектирование в ситуацию невозможности обеспечения необходимого качества.
Такая проверка на реалистичность должна также присутствовать для того, чтобы принимать во внимание существующие компоненты ("черные ящики"). Еще одним граничным условием является учет доступных для нас продуктов. Не откладывайте на самый конец анализа проверку того, можно ли объединить в целое изученные вами кооперации.
Короче говоря, фрактальное мышление стимулирует нас принимать во внимание все аспекты на всех уровнях анализа сразу.
Мы не предполагаем, что данный процесс будет полностью итеративным или выполняемым в несколько проходов. Архитектор должен находить правильные точки для передачи информации для дальнейшей детализации, чтобы не приходилось возвращаться к архитектурным решениям при реализации. Именно по этой причине физическая реализация архитектуры в виде выбора конкретных продуктов выполняется на как можно более ранней стадии, задолго до того, как формируется подробный дизайн. Такой поход отличается от традиционного подхода, используемого в методах OOAD. Архитектор должен принимать во внимание фактор достижимости при реализации, чтобы свести к минимуму пересмотр архитектурных решений.
Цель состоит в том, чтобы максимально отдалить принятие конкретных решений по дизайну. Принимайте эти решения только в следующих случаях:
Решения принимаются на том уровне анализа, на котором они могут быть полностью оправданы. Этими уровнями могут быть:
Метод с проведением семинаров и разработкой по контракту вполне поддерживает применение данного подхода.
Использование средств моделирования и работы с метаданными для продвижения
по стадиям архитектурной детализации и для управления сложностью разработки
программного обеспечения являются одним из аспектов разработки, управляемой
моделями
MDD – это подход, при котором:
MDD предлагает подход, при котором бизнес-аналитик может зафиксировать биз-
нес-процессы в модели, независимой от вычислений (Computation Independent Model,
(рис 3.13) Архитектура, управляемая моделямиЧтобы инструменты могли обмениваться программными артефактами и размещать код и другие артефакты, такие, как спецификации конфигураций, на рабочих платформах, необходимы стандарты моделирования и работы с метаданными.
Артефакты, создаваемые на каждом этапе, должны быть определены командой разработки с использованием модели процесса, например Rational Unified Process (RUP). Хотя в данном курсе основное внимание уделяется области разработки, не менее важны и другие области – тестирование, удобство использования и управления системой, а также вопрос внедрения решения в пользовательское сообщество. Должно ли решение продаваться, предлагаться как часть обслуживания или как часть специальной разработки в пределах конкретного предприятия? Люди, работающие над этими аспектами, должны постоянно участвовать в процессе разработки, чтобы разработка, тестирование и удобство использования находились в связи с наиболее важными аспектами решения.
Основные преимущества, которые дает тщательное следование подходу MDD, следующие:
MDD снижает стоимость разработки программного обеспечения с помощью генерации кода и артефактов по моделям, что повышает производительность труда разработчика.
При добавлении новой бизнес-функции вам нужно только разработать поведение, относящееся к этой новой функции. Вся остальная информация, необходимая для генерации артефактов реализации, уже заключена в трансформациях.
MDD способствует тому, чтобы артефакты генерировались согласованно.
Подход MDD особенно хорош, если его применять на уровне программы или организации. Использование опробованных и протестированных трансформаций повышает предсказуемость при разработке новых функций и уменьшает риск, поскольку архитектурные и технические проблемы были уже разрешены.
Модели гораздо ближе к предметной области проблемы, и их гораздо проще донести. Совершенствование процесса коммуникации способствует созданию решений, лучше соответствующих целям бизнеса.
Модели облегчают понимание и обоснования системы на уровне дизайна. Тот факт, что модели являются частью определения системы, а не частью документации, означает, что модели никогда не будут устаревшими или недостоверными.
В моделях фиксируется опыт. Явное сохранение опыта обеспечивает сохранение знаний, даже если эксперты покинут организацию.
В MDD модели – это важное достояние, в которых фиксируется то, что делают ИТ-системы организации. Высокоуровневые модели устойчивы к изменениям, связанным с совершенствованием платформенного уровня. Они изменяются только тогда, когда изменяются бизнес-требования.
При использовании MDD ранняя стадия разработки приложения в основном
касается моделирования. Это означает, что существует возможность отсрочить
выбор конкретной
В создаваемом нами решении мы лишь слегка касаемся преимуществ, которые может дать MDD. Однако опыт, который компания LGI приобретает при использовании средств моделирования для описания решения, – это первый шаг в процессе повышения зрелости используемого подхода, что даст существенные выгоды в будущем.
Разработка, управляемая моделями? – это подход к разработке, при котором главными
артефактами являются модели (а не программы). Модели могут поэтапно трансформироваться,
пока не будет создан базовый код. На рис. 3.14 показан пример
трансформации
(рис 3.14) Трансформация моделейЧтобы трансформировать нашу бизнес-проблему в решение, использующее разработку, управляемую моделями, мы будем применять различные инструменты. Мы должны понять, какой тип инструментов необходимо использовать для каждой роли в разработке, а затем должны понять, как модель будет передаваться от инструмента к инструменту и какие ограничения накладывает передача артефактов от одного инструмента к другому.
Идеалом является создание двунаправленной
В настоящее время имеющаяся цепочка инструментов поддерживает только
однонаправленный (или каскадный) подход к MDD. Обращение модели процесса –
дело будущего. Так что при принятии решения о том, как использовать эти инструменты,
важно принимать во внимание, что после того, как модель была экспортирована
из одного инструмента в другой, внесение изменений в вышестоящий инструмент
будет требовать больше времени и средств. Изменения, внесенные в вышестоящий
инструмент, также должны вручную быть переработаны в нижестоящих
Это одна из причин, по которым вас следует четко понимать области ответственности
и
На рис. 3.15 показана цепочка инструментов, на которой мы основывали нашу разработку. Бизнес-процесс фиксируется в инструменте для бизнес-моделирования бизнес-аналитиками. Эта модель используется двумя способами (см. пункт А на рис. 3.15). Она применяется для генерации определений процессов для оркестровки рабочих потоков, а также для моделирования архитектуры решения. Модель архитектуры решения содержит шаблоны, интерфейсы, модель размещения и схемы последовательностей. В оркестровке рабочих потоков процесс и архитектура рабочих потоков объединяются с последовательностью, потоками и выбранными сообщениями. Архитектурные модели и оркестровка рабочих потоков используются инструментами создания кода. На рис. 3.16 показана цепочка инструментов, которую мы применяли в этом курсе.
(рис 3.16) Цепочка инструментов(рис 3.15) Цепочка инструментов, использованная в данном курсеИспользуемая нами цепочка инструментов не имеет возможности для автоматического
включения в модель шаблонов Patterns for e-business. Мы применили инструменты
с Web-сайта Patterns for e-business для выбора шаблонов, которые потом перенесли
в Microsoft Visio. После того как мы согласовали шаблоны, мы перенесли получившуюся
схему размещения в Rational
Ниже приводится суммарный список использованных нами инструментов.
На основе входных данных, полученных из WebSphere Business Integration Modeler
и интерфейсов имеющихся реализаций, Rational
Главные артефакты, которыми архитекторы обмениваются с инструментами ИТ-специалистов,
является код BPEL, FDL и
В этой лекции описан подход, который мы применяли при разработке и интеграции
нового процесса работы с внешними
Выполнить проект, связанный с интеграцией так, чтобы все были удовлетворены, оказывается сложнее, чем выполнить проект по разработке с нуля. Главная причина этого – трудности общения между людьми, представляющими различные аспекты решения, которые с самого начала проекта борются друг с другом за внимание к своим целям. Метод, который мы описали в этой лекции и которому следуем, позволяет усовершенствовать общение между разными ролями, задействованными в проекте, акцентируя внимание на том, что нужно сделать для удовлетворения требований, представленных в бизнес-процессе. При этом используется общая платформа, упрощающая обмен артефактами в решениях, и общие языки моделирования, обеспечивающие взаимозаменяемость артефактов. В лекции 4, "Бизнес-процесс", мы начинаем рассматривать моделирование бизнес-требований.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.