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

Одной из наших целей, обозначенных в разделе 1.3, "Цели и ограничения, связанные с информационными технологиями", является повышение производительности разработки при использовании современных инструментов и технологий. Новая система реализует сервис-ориентированную архитектуру (Service-Oriented Architecture, SOA), основанную на Web-службах. Будет вестись разработка, направляемая моделями (Model Driven Development, MDD), и будут использоваться технологии на основе открытых стандартов, такие, как J2EE, BPEL и UML2. Проект разработки будет справочником по использованию этих технологий в будущем и будет показывать, как добиться увеличения производительности.

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

3.1 Организация бизнеса, работающего по требованию

Что такое бизнес по требованию (On Demand Business)? IBM определяет его как бизнес, руководители которого могут видеть свою компанию и управлять ею как единым целым. Это означает, что все отрасли бизнеса должны задействовать друг друга в ходе динамических преобразований ранее изолированных операций, проводимых отдельными подразделениями, в цельный интегрированный бизнес-процесс, охватывающий всю компанию, а также клиентов за ее пределами.

Бизнес по требованию имеет четыре наиболее существенные характеристики:

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

За дополнительной информацией о бизнесе по требованию обращайтесь на сайт http://www-306.ibm.com/e-business/ondemand/us/overview/overview.shtml

Компания LGI преобразует себя в бизнес по требованию следующим образом:

Преобразуя свою ИТ-инфраструктуру в инфраструктуру на основе открытых стандартов, что делает LGI более гибкой и готовой к ответу на изменение нужд бизнеса.

При разработке решений акцент делается на новых или более эффективных бизнес-процессах, включающих в себя клиентов, подразделения и поставщиков.

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

3.1.1 Операционная среда, работающая по требованию

Операционная среда, работающая по требованию, имеет две цели – упрощение работы с ИТ и повышение гибкости бизнеса. Она представляет собой набор средств управления интеграцией и инфраструктурой, который на модульной и инкрементной основе может использоваться клиентами и партнерами для обеспечения перехода к бизнесу по требованию. Эта среда состоит из двух частей – управление инфра-структурой и управление интеграцией, которые решают задачи упрощения работы с ИТ и повышения гибкости бизнеса. Обращайтесь к книге серии IBM Redbook под названием "On Demand Operating Environment: Creating Business Flexibility", SG24-6633, где предлагается план работ по обеспечению гибкости бизнеса в операционной среде, работающей по требованию.

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

Рис. 3.1. Операционная среда по требованию

В решении для работы с внешними оценщиками компания LGI использует бизнес-моделирование (Business Modeling), трансформацию процессов (Process Transformation) и интеграцию приложений (Application Integration). В будущем LGI планирует применять управление бизнес-процессами (Business Process Management) для наблюдения за повседневными операциями и анализа производительности процесса. В операционной среде по требованию эти возможности реализованы с использованием сервис-ориентированной архитектуры (Service Oriented Architecture, SOA). SOA связана с упрощением операционной среды, поскольку облегчается использование сочетаний разных возможностей и установление соответствий между ними, а также с предоставлением интегрированной среды разработки программного обеспечения для создания решений^{1Mike Perrow, "Building the On Demand Business: Four Imperatives for Improved Software Development", http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/imperatives-04.pdf} из служб при помощи сервис-ориентированного моделирования^{2Ali Arsanjani, "Service-oriented modeling and architecture", http://www-128.ibm.com/developerworks/webservices/library/ws-soa-design1/} .

3.1.2 Сервис-ориентированное моделирование

Интерес к сервис-ориентированному моделированию возрастает в связи с пониманием того, что существующие процессы разработки и нотации, такие, как объектно-ориентированный анализ и проектирование (Object-Oriented Analysis and Design, OOAD), корпоративная архитектура (Enterprise Architecture, EA) и моделирование бизнес-процессов (Business Process Modeling, BPM), лишь частично охватывают архитектурные шаблоны, возникающие сегодня под эгидой SOA. Таким образом, необходим улучшенный междисциплинарный подход к моделированию служб^{3Olaf Zimmermann, Pal Krogdahl, Clive Gee, Elements of Service-Oriented Analysis and Design, June 2004 Web-сайт IBM developerWorks: http://www-128.ibm.com/developerworks/webservices/library/ws-soad1/} .

Место, которое занимают OOAD, EA и BPM, эти авторы описывают так, как показано на рис. 3.2.

Рис. 3.2. Позиционирование BPM, EA и OOAD (Zimmerman et al., Service-Oriented Analysis and Design)

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

• со службами (WSDL);
• оркестровкой служб (BPEL);
• сервисной шиной (ESB);
• шаблонами служб.

Идея упомянутых авторов состоит в том, что каждый из процессов, OOAD, EA и BPM, предлагает некоторые из элементов, необходимых для построения сервис-ориентированной архитектуры. Однако по отдельности их недостаточно. Методы необходимо интегрировать. В результате в разработке программного обеспечения у нас получается такая же изоляция по подразделениям, как и при его использовании. Поверните схему на 90 , и вы увидите сходство!

В разделе 3.1.3, "Платформа разработки программного обеспечения от IBM", описывается стратегия, лежащая в основе платформы разработки от IBM, ориентированная на интеграцию различных ролей и операций, задействованных в разработке программного решения.

3.1.3 Платформа разработки программного обеспечения от IBM

IBM рассматривает разработку программного обеспечения как стратегический бизнес-процесс. Разработка выигрывает от горизонтальной интеграции как любой другой бизнес-процесс. IBM основывает свои инструменты разработки программного обеспечения на общей платформе разработки (software development platform, SDP), поддерживая тем самым концепцию того, что разработка – это бизнес-процесс, такой же, как цепь поставки или управление связями с заказчиками (рис. 3.3 )^{4Alan Brown, Realizing the IBM Software development platform, April 2004: http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/SDP_WP_Final.pdf} , целью которого является поддержка преобразования бизнеса в ходе интеграции и автоматизации горизонтальных бизнес-процессов.

увеличить изображение
Рис. 3.3. Разработка программного обеспечения: стратегический бизнес-процесс

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

Платформа разработки программного обеспечения от IBM преследует следующие цели:

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

Соединение нужд бизнеса с ИТ-решениями

Моделирование бизнес-процессов, моделирование информации и Rational Unified Process являются основными средствами соединения нужд бизнеса с ИТ-решениями.

Мы уделим основное внимание использованию моделирования бизнес-процессов для соединения нужд бизнеса с ИТ-решением в сценарии работы с внешними оценщиками.

Создание команд специалистов-практиков

Программная платформа Eclipse в сочетании с каркасом Eclipse Modeling Framework (EMF) являются ключевыми технологиями SDP, позволяющими командам практиков совместно работать над общей моделью решения, основанной на UML2 (рис. 3.4).

Рис. 3.4. Платформа разработки программного обеспечения (Alan Brown в упомянутой работе)

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

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

1. Соединение модели бизнес-процесса, созданной бизнес-аналитиком в WebSphere Business Integration Modeler, с архитектурой, созданной архитектором решения в Rational Software Architect. WebSphere Business Integration Modeler и Rational Software Architect недавно были интегрированы друг с другом на основе UML2 и метода доступа к общей бизнес- модели^{5См. прил. "B", "Вопросы интеграции", где приводится подробная информация.}.
2. Специалист по интеграции IT-процессов создает исполняемый бизнес-процесс при помощи WebSphere Studio Application Development Integration Edition, применяя модель процесса из WebSphere Business Integration Modeler, и определения интерфейсов из Rational Software Architect.
3. Специалист по рабочим ИТ-потокам поддерживает FDL-процесс при помощи WebSphere MQ Workflow Buildtime. Этот специалист использует модель процесса из WebSphere Business Integration Modeler и WebSphere MQ Workflow и определения интерфейсов из Rational Software Architect.
4. Разработчик приложений перерабатывает приложения для обработки претензий, созданные в WebSphere Studio Application Developer, чтобы в них использовались Web-службы, применяя для этого WSDL-определения и Web-службы, а также UML-архитектуру, создаваемую архитектором решения.
5. ИТ-специалист по интеграции сервисной шины создает посреднические модули, которые размещаются на корпоративной сервисной шине при помощи WebSphere Business Integration Message Broker с применением WSDL и определений интерфейса схем, содержащихся в Rational Software Architect.

Полная видимость, снижение затрат и управление рисками

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

В данном проекте мы не использовали RUP для определения процесса разработки и управления им, Requisite pro – для управления требованиями, ClearQuest и Clearcase – для управления требованиями или какие-либо другие инструменты тестирования и создания профилей производительности, входящие в платформу разработки программного обеспечения от Rational.