Этап анализа поведения ПС

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

– моделирование предметной области;

– построение объектной системы;

– адаптация объектной системы.

Моделирование предметной области определяется степенью формализации и уровнем детализации в предоставлении знаний относительно предметной области. Главные задачи этого процесса являются типичными и состоят:

– в определении базовых понятий и терминов предметной области, а также реальных объектов, которые им отвечают;

– в определении отношений и связей между этими понятиями соответственно отношениям и связях между реальными объектами, которые важные для функциональности будущей ПС;

– в построении моделей, которые отображают различные аспекты предметной области: структурные, поведенческие, последовательности действий, потоки данных и пр.

Результаты моделирования могут уточняться и детализироваться на иных этапах с целью наиболее полного описания предметной области. В частности, важным моментом является согласование терминов и понятий по результатам моделирования и терминологии описания бизнесов–процессов.

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

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

Этап спецификации интерфейсов и взаимодействия компонентов

Этот этап есть ключевым моментом, когда специфика компонентного подхода начинает играть главную роль в создании ПС. Предыдущие этапы повторяют соответствующие этапы объектно–ориентированного подхода. Основу компонентного подхода составляют иные аспекты. Для объектов существуют много реализованных и готовых к применению компонентов и их необходимо предоставить так, чтобы можно было задействовать механизмы их поиска, выборки и интеграции в единую среду. Эта цель и определяет главную задачу этапа спецификации интерфейсов и взаимодействия компонентов, что соответствует следующим процессам:

– распределение ролей компонентов;

– проектирование и спецификация отдельных интерфейсов;

– описание взаимодействий компонентов.

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

Проектирование и спецификация интерфейсов. Проектирование интерфейсов происходит соответственно ролям компонентов. Важно придерживаться концепции оптимальности в проектировании – интерфейсов для компонента не должно быть много, но в тот же время не нужно проектировать мало, но большие по размеру интерфейсы. Каждый из типов интерфейсов – клиентский или сервисный – проектируется в отдельности, идентифицируется и определяется состав поддерживаемых ими операций. Описание отдельных интерфейсов проводится в языке IDL для модели CORBA.

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

Описание взаимодействия компонентов выполняется в контексте последовательности действий (workflow), поддерживающих определенные бизнес–процессы. Если результат проектирования интерфейсов определяет пары взаимодействующих компонентов, то результатом этого процесса является совокупность последовательностей операций всех компонентов для достижения целей выполнения бизнесов–процессов.

Этап интеграции

Главными задачами этого этапа является определение, поиск и выбор всех необходимых компонентов, их адаптация, определение плана компонентной конфигурации, создание и тестирование интегрированной среды для ПС. Поиск и выбор компонентов объединяются в одну задачу, что называется квалификацией (Component Qualification), а интеграция компонентов определяется как композиция, которая разделяется на несколько видов в зависимости от комбинаций компонентов. Входными данными процесса являются описания:

– интерфейсов компонентов на языке описания интерфейсов;

– взаимодействие компонентов описывается соответственно последовательностями операций для выполнения функций в ПС;

– дополнительные условия и данные для интеграции и управления компонентами.

На этапе интеграции соответственно выполняются следующие процессы:

– поиск компонентов соответственно описанию интерфейсов;

– выбор совокупности компонентов, которые обеспечивают необходимую функциональность;

– адаптация существующих компонентов к требованиям построения интегрированной среды;

– создание новых компонентов, для которых результаты поиска, выбора и адаптации не дали требуемых результатов;

– инсталляция компонентов для потребностей интеграции;

– определение полной совокупности правил и условий интеграции;

– непосредственное построение проекта;

– тестирование интегрированной среды.

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

Для предоставления и поиска информации могут быть примененные поисковые машины сети Интернет, как, например, AltaVista,. проект Agora, нацеленный на разработку поисковой машины, для которой критериями поиска есть компонентные модели и их свойства.

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

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

– расширение существующих интерфейсов компонентов с целью соответствия интерфейсам в интегрированной среде;

– обеспечение дополнительных реализаций компонентов с сохранением своих интерфейсов;

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

Создание компонентов. Этот процесс выполняется, когда предыдущие процессы поиска, выбора, адаптации для определенных компонентов дают отрицательные результаты. В этом случае необходимо создавать новые компоненты с заранее определенными интерфейсами и функциональностью. Для правильного построения новых элементов используется модель Enterprise java beans (EJB), в состав которой входят:

– сервер EJB, как прикладной сервер, в среде которого загружаются и выполняются один или больше контейнеров EJB;

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

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

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

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

Определение правил и условий интеграции. Правила и условия интеграции зависят от компонентной модели, практическое применение имеют три:

– COM/DCOM/COM+, реализованная в операционных системах семейства WINDOWS;

– система CORBA [11], которая поддерживается на различных платформах;

–Javabeans и enterprise javabeans [13] на базе JAVA–технологий, которые функционируют на платформах, для которых реализованы виртуальные JAVA–машины.

Построение проекта.Главная цель процесса – выполнить все действия относительно подготовки интегрированной среды к функционированию и создание плана конфигурации компонентов ПС.

Тестирование интегрированной среды.При тестировании решаются две задачи:

– проверка функциональности ПС;

– проверка возможности совместимой работы компонентов системы.

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

Вторая задача – специфична для компонентного подхода, она имеет факторы, которые влияют на проверку совместной работы компонентов:

1. Инициирование работы интегрированной среды для ПС.

2. Определение инфраструктуры для создания возможности динамического взаимодействия компонентов во время выполнения и распределения клиент–серверных запросов в системе.

3. Для каждой пары компонентов, которые взаимодействуют, один с них является клиентом, а второй – сервером. Серверы функционируют в режиме ожидания, пока клиенты к ним не обратятся. Механизм поддержки режима функционирования на уровне операционной среды является механизмом сервисов.

4. Схема взаимодействия компонентов в ПС является ориентированным графом. Приведенные факторы и определяют порядок и содержание второй задачи для проведения тестирования:

– проверка процедуры старта ПС;

– проверка функционирования и создания инфраструктуры для поддержки компонентной модели;

– проверка корректности регистрацииї сервисов и возможности взаимодействия с ними с различных компьютеров сети;

– проверка корректности последовательностей инициирования сервисов.