CC BY
44
тия статических и динамических интерфейсов класса. Статические интерфейсы предназначены решать задачи реализации функционала, не требующего создания экземпляров классов. Это экономит время, поскольку создание экземпляра требует дополнительного времени. Динамические же интерфейсы принадлежат экземплярам класса и решают те же задачи, что и в COM.
Была введена возможность явно указывать параметры при создании классов, в числе которых обязательно присутствует указатель на внешнюю память для решения задач создания на сторонней памяти. Кроме того, был стандартизирован способ получения информации о классе по произвольному интерфейсу, в том числе его уникальный идентификатор. Идентификаторы классов и интерфейсов такие же, как и в COM, то есть это всем известный GUID. Тем самым предоставляется возможность идентификации класса объекта, что востребовано при передаче параметров указателей на интерфейсы. Например, когда требуется преобразовать указатель произвольного интерфейса к какому-то определенному типу C++ класса реализации. Такие задачи можно решать и путем реализации отдельного интерфейса с последующей попыткой его запроса, но для программирования это не очень удобно, и код получается более громоздким и запутанным. Ведь концепция интерфейсов призвана обеспечить инкапсуляцию данных и реализации, а в данном случае это будет избыточно.
У каждого класса есть свой интерфейс входной точки ¡Entry- _
Модуль
РоШ_..., в котором реализованы методы создания экземпляра класса с произвольными параметрами и методы получения необходимого размера внешней памяти. Метод создания класса может возвращать предопределенный интерфейс, чтобы облегчить его использование при программировании. Через интерфейс входной точки также можно получать статические интерфейсы. Аналогом интерфейса входной точки в СОМ является
Рис. 1. Структура модуля
интерфейс фабрики классов, который тоже можно получить через него. Таким образом, при описании класса описывается его собственный интерфейс входной точки с собственным методом создания с параметрами.
Класс
О
о-
Статическая реализ;
IEntryPoint
IClassFactory
Динамическая реализация
IPrObject
IMyAPI
-О -О
Рис. 2. Структура класса
Схема создания экземпляра класса такова: сначала происходит загрузка модуля в память и получается указатель на функцию DllGetClassOb-ject, аналогично с COM; затем через эту функцию получается указатель на интерфейс входной точки нужного класса либо указатель на статический интерфейс и уже через интерфейс входной точки путем вызова метода создается экземпляр объекта.
Автором разработана и реализована компонентная модель, позволяющая эффективнее и проще использовать все преимущества компонентного подхода в программных комплексах любой сложности. Технология позволяет максимально быстро создавать экземпляры классов, делать более понятными описания интерфейсов и связей их с классами, упрощать оперирование интерфейсами. Технология является расширением модели COM фирмы Microsoft.
Список литературы
1. Фаулер М. Рефакторинг: улучшение существующего кода. / Пер. с англ. - СПб.: Символ-Плюс, 2005. - 432 с.
2. Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования. - СПб.: Питер, 2003. - 368 с..
3. Деннинг А. ActiveX для профессионалов. - СПб.: Питер, 1998. - 624 с.
4. Чеппел Д. Технологии ActiveX и OLE. / Пер. с англ. -М.: Русская редакция, 1997. - 320 с.
5. Роджерсон Д. Основы COM. / Пер. с англ. - М.: Русская редакция, 1997. - 376 с.
6. Рихтер Д. Windows для профессионалов (программирование в Win32 API для Windows NT 3.5 и Windows 95). / Пер. с англ. - М.: Издат. отдел «Русская редакция» ТОО «Channel Trading Ltd», 1995. - 720 с.
ПРОГРАММНАЯ СИСТЕМА УПРАВЛЕНИЯ БИЗНЕС-ПРОЦЕССАМИ
ПРЕДПРИЯТИЯ
К.Н. Коробков (Российский государственный социальный университет, Москва)
В настоящее время среди руководителей все большую популярность приобретает процессный
подход к управлению организацией. Данный подход предполагает рассмотрение деятельности
внутри организации как совокупности процессов взаимодействия между сотрудниками и структурными единицами организации (отделами, цехами и т.д.). Именно по этой причине в сфере управления предприятием, согласно потребностям рынка корпоративного ПО, вместо традиционных ERP-систем большую популярность стали приобретать программные продукты, относящиеся к классу BPM (Business Process Management), призванные управлять бизнес-процессами (БП) организации. Стандарт ISO/CD 15531-1 определяет понятие БП как «структурированный набор действий (задач), охватывающий различные сущности предприятия и подчиненный определенной цели».
BPM-система описывает деятельность компании как совокупность БП (производственных, обслуживающих, управленческих), каждая из которых состоит из множества задач, связанных между собой (см.: Вил ван дер Аалст, Кейс ван Хей. Управление потоками работ: модели, методы и системы. - М., 2007.). Задача является элементарной единицей БП и исполняется одним ресурсом (человеком, устройством, программным модулем). Между задачами по связям передаются результаты, материальные или электронные объекты, которые создаются и изменяются в бизнес-процессе.
В компании "Асис Софт" (г. Зеленоград) создана и успешно апробирована система управления БП Asys BPM. Система разработана в среде программирования C++ Builder 6. Автор статьи принимал непосредственное участие в создании данной системы. Архитектура Asys BPM представлена на рисунке 1.
Рис. 1. Архитектура системы Asys BPM
Опишем назначение программных компонент Asys BPM.
• Asys Designer. Эта компонента реализует функции создания и редактирования описаний (схем) БП в системе. Данное описание представляется в виде связного графа, узлами которого являются обычные задачи, условные переходы и т.д. В качестве стандарта для наглядного визуального отображения схемы БП в Asys Designer применяется нотация BPMN (Business Process Modeling Notation).
• Asys Engine. Данная компонента предназначена для выполнения конкретных реализаций БП, описанных в системе. Сюда можно отнести управ-
ление маршрутизацией результатов, регистрацию выполнения задач и т.д.
• Asys Monitor. Эта компонента позволяет получать информацию о выполнении реализаций БП и анализировать данную информацию с помощью различных диаграмм. Также у данной компоненты присутствуют функции создания отчетности по анализируемой информации.
• Asys TSW. Данная компонента является клиентским приложением, информирующим пользователя о назначенных ему задачах в тех или иных БП и предоставляющим средства для решения данных задач. Asys TSW также имеет функции управления учетными записями и правами доступа пользователей к системе. Эти функции доступны только для администраторов.
Различают следующие типы задач в БП:
- ручные задачи, которые выполняются человеком, без использования приложений;
- автоматизированные задачи, которые выполняются без участия работников;
- полуавтоматизированные задачи, исполняемые и людьми, и приложениями.
При выполнении всех указанных типов задач создаются или изменяются результаты. Результат на физическом уровне представляет собой структуру с набором полей различного типа в базе данных. Количество и типы полей у разных результатов могут варьироваться. Фактически результат отражает какой-либо объект с указанием его характеристик. Таким образом, Asys BPM может учитывать и контролировать как электронные, так и материальные объекты. В этом состоит существенное преимущество по сравнению с системами, работающими с четко определенными типами результатов, например, с системами электронного документооборота.
Для выполнения автоматизированных и полуавтоматизированных задач в Asys BPM используются программные сервисы.
Сервис - это программный модуль, взаимодействующий через особый интерфейс, предназначенный для выполнения определенной задачи.
Сервис в процессе описания БП назначается на задачу в качестве ресурса.
Сервис для полуавтоматизированной задачи вызывается с помощью Asys TSW, когда работник начинает выполнять данную задачу.
Примером такого сервиса является форма регистрации входящей корреспонденции, определенная в отдельном программном модуле, а названием задачи для пользователя может быть "Регистрация входящих документов". Работник при выполнении такой задачи заполняет или изменяет информацию, содержащуюся в данной форме.
Автоматизированные задачи также выполняются с помощью сервисов, которые запускаются в данном случае компонентой Asys Engine, без участия человека. В качестве примера можно привес-
ти автономный сервис, выполняющий архивацию для определенных документов в соответствии с заданными заранее параметрами. Сервис может быть как локальным, работающим на одном ПК с Asys TSW, так и сетевым, то есть взаимодействующим через вычислительную сеть с другими сервисами и программами. Использование сервисов позволяет уйти от концепции монолитного программного обеспечения, где все функции заключены в одной большой программе. Однако такой подход имеет недостатки, связанные, в частности, с тестированием взаимодействия сервисов.
Часто возникает необходимость в использовании одних и тех же задач в разных БП. Такие задачи характеризуются уже определенным исполнителем, назначенным сервисом и указанными входными и выходными результатами. Asys Designer позволяет определять данные задачи как типовые и, соответственно, помещает их в специальный репозиторий для дальнейшего использования в других БП. Помимо задач, в качестве типовых элементов могут быть определены группы задач или целые процессы. Репозиторий хранит типовые объекты в БД. В компоненте Asys Designer у репозитория типовых элементов есть специальная панель, где в виде списка, разделенного по категориям, представлены графические изображения и названия типовых элементов. Данные элементы добавляются на область формирования схемы БП с помощью процедуры Drag and Drop. После добавления пользователю для включения типового элемента в схему БП необходимо соединить входные и выходные связи элемента с задачами в схеме. Использование типовых элементов позволяет в дальнейшем сократить время на разработку схем БП.
Типовые элементы, находящиеся в схеме БП, не могут редактироваться как обычные задачи. Для этого предусмотрен специальный "тестовый" режим в Asys Designer. Изменения, произведенные в этом режиме с типовым элементом, распространяются на экземпляры данного элемента во всех БП, где он указан. Помимо редактирования, в данном режиме существует возможность тестирова-
ния типового элемента. Целью данного тестирования является проверка работы сервисов, назначенных на задачи внутри типового элемента. При этом на вход данного типового элемента должны подаваться тестовые результаты для проверки работы сервисов.
Тестовые результаты создаются конструктором БП явно или генерируются с помощью специальных тестовых сервисов. Процесс тестирования отображается на графической схеме, где отмечается, в какой именно задаче типового элемента находится тестовый результат. Существует возможность просмотра и сравнения входных и измененных выходных результатов для всех задач типового элемента. В этом режиме возможно тестирование типовых элементов, содержащих и автоматизированные, и полуавтоматизированные задачи. Полуавтоматизированные задачи исполняются самим конструктором БП при тестировании типового объекта. В тестовом режиме можно производить имитационное моделирование построенных процессов до использования их в работе.
Кроме того, в компоненте Asys Designer предусмотрены возможности по анализу построенных схем БП. Для каждой задачи конструктором БП задается планируемое время ее выполнения. На основе этих данных производится сетевой анализ схемы БП и вычисляются ранний и поздний сроки начала выполнения для каждой задачи. Для всего процесса в данном случае вычисляется ранний срок завершения, поздний и наиболее реальный. Помимо этого, в компоненте Asys Designer предусмотрена функция нахождения кратчайшего пути от начальной задачи к конечной с использованием алгоритма Беллмана-Форда. Это особенно полезно, если схема насчитывает несколько десятков элементов.
Следует отметить, что Asys BPM использует два развивающихся в рамках информационных систем направления - сервис-ориентированую архитектуру и технологию управления БП. Использование сервисов позволяет таким BPM-системам наилучшим образом интегрироваться с другими информационными системами.
ПРЕДСТАВЛЕНИЕ ДРЕВОВИДНОЙ ЗАВИСИМОСТИ В РЕЛЯЦИОННОЙ БАЗЕ ДАННЫХ
Н.Н. Гребенщиков (Хакасский государственный университет им. Н.Ф. Катанова, г Абакан)
При построении реляционной базы данных (РБД), где между данными существует древовидная зависимость, разработчики встают перед выбором метода представления такой зависимости в реляционной модели. Существует несколько ме-
тодов: например, авторы Joe Celko и Vadim Tropashko описывают методы, в которых используются список смежности, материализация пути в дереве, вложенные множества и интервалы, транзитивное замыкание. В ходе разработки структуры
