Разработка программного обеспечения (ПО) представляет собой процесс, сложность которого определяется уровнем понимания используемых современных технологий и автоматизируемых бизнес-процессов. На каждом этапе команде разработчиков необходимо принимать решения при наличии сложной, не всегда полной и разносторонней информации. Поэтому возникают проектные риски: управленческие, функциональные и технические. Первые связаны с принятием решений, касающихся проектной команды. Функциональные риски возникают из-за изменений в бизнес-требованиях. Третьи – с выбором используемых информационных технологий, архитектуры программного обеспечения. Успешность проекта во многом зависит от успешности управления рисками – выявление рисков и разработка мероприятий по их недопущению. Использование формализованных методов описания проектных решений и методов проектирования ПО (например, структурный или объектно-ориентированный) позволяет снизить риски и повысить качество разрабатываемых систем.
Основной целью исследования является совершенствование метода агентно-ориентированного проектирования информационных систем для предметной области процессов преобразования ресурсов и его адаптация при проектировании веб-сервисов.
Материалы и методы исследования
Важный вопрос на начальном этапе разработки информационной системы (ИС) – выбор архитектуры. Исторически первой появилась монолитная архитектура. ИС, разработанная по этой концепции, представляет собой единое приложение, которое состоит из пользовательского интерфейса, серверного приложения и базы данных. Все части ИС взаимосвязаны и взаимозависимы. Это имеет свои достоинства и недостатки. К положительным моментам относятся: простое и быстрое развертывание приложения, минимизация проблем, связанных со взаимодействием компонент. К недостаткам можно отнести: сложность внедрения новых информационных технологий, также в результате доработок ИС код приложения становится громоздким и трудным для понимания [1].
Развитие информационных технологий привело к появлению новой сервис-ориентированной архитектуры (SOA). ИС, разработанная в соответствии с этой архитектурой, представляет собой совокупность отдельных модулей, взаимодействующих друг с другом по стандартизованному протоколу. SOA разделяет компоненты по двум основным ролям: поставщик и потребитель сервисов. Обе эти роли могут играть программные агенты [1]. Плюсами этой архитектуры являются: повторное использование отдельных модулей в других проектах, независимость модулей приводит к более простому внесению доработок и развитию ИС. Основная проблема этой архитектуры – управление обменом сообщений между сервисами [1].
Микросервисная архитектура стала развитием сервисно-ориентированной. Приложение состоит из автономных компонентов, которые взаимодействуют между собой посредством API (Application Programming Interface) [2].
Результаты исследования и их обсуждение
Метод проектирования ИС на основе агентного подхода
Организационно-техническая система (ОТС) представляет собой совокупность организационной структуры и находящихся в ее распоряжении технических средств, т.е. совместно рассматривается человек и информационная система. Современные тенденции информатизации – не просто автоматизация бизнес-процессов предприятия, а создание виртуальной организации, охватывающей всех участников процесса. Поскольку для ОТС характерны процессы принятия решений (знания, сценарии, согласования), то метод проектирования таких систем должен включать в себя формализацию и информатизацию процессов принятия решений (ППР). Лица, принимающие решения, могут рассматриваться как интеллектуальные агенты. Таким образом, ОТС может быть рассмотрена как мультиагентная система (МАС). Существующий метод ППР при разработке информационных систем состоит из нескольких этапов [3].
Первый этап – обследование процессов ОТС. На данном этапе проводится обследование предметной области. Затем, на основании полученных данных строится имитационная модель «как есть» деятельности обследуемого предприятия. При этом используется модель мультиагентных процессов преобразования ресурсов, которая основана на интеграции имитационного, экспертного, ситуационного и мультиагентного моделирования [4, 5].
Второй этап – проводятся имитационные эксперименты с моделью «как есть» с целью выявления «узких мест» в организации процессов. По результатам моделирования строится динамическая модель мультиагентных процессов преобразования ресурсов (МППР) [4, 5] «как будет». К основным элементам модели МППР относятся: ресурсы, заявки, средства, операции, агенты.
Далее, переходим к следующему этапу – проработка проекта. Отличительной особенностью предлагаемого метода является возможность использовать данные модели процессов ОТС для построения модели ИС в нотациях IDEF0 и DFD. Дополнительно, на данном этапе при построении модели ИС предложено использовать результаты структурного анализа, как основы для объектно-ориентированного проектирования.
В ходе дальнейшего объектно-ориентированного проектирования с использованием языка UML достигается построение полной модели, проектируемой ИС, включающей в себя компоненты мультиагентной имитационной модели МППР. На основании модели ИС получаем заготовки программных модулей и переходим к третьему этапу – разработке системы. Для формализации и реализации микросервисной архитектуры можно использовать концепцию МППР, поскольку она включает в себя агентов, ресурсы и операции.
Понятие «агент» соответствует аппаратно или программно реализованной сущности, которая способна действовать в интересах достижения целей, поставленных перед ней владельцем и/или пользователем, обладающей интеллектуальными способностями [6–9].
Мир агента составляет его окружение: 1) ресурсы, средства, заявки, за которыми он наблюдает; 2) операции и агенты, которыми он управляет; 3) агенты с которыми он обменивается информацией и взаимодействует. С точки зрения проектируемой ИС с помощью агентов могут быть формализованы модели поведения пользователей или отдельных компонент программной системы.
На этапе формализации предметной области с помощью модели МППР могут быть формализованы как программные компоненты (не только автономные), но и модели поведения пользователей. Вопросы моделе- и агентно-ориентированного проектирования освещаются в работах В.А. Виттиха и П.О. Скобелева [10, 11], Б.В. Соколова [12]. Концептуальная модель предметной области МППР включает в себя Агентов [3]. При переходе к модели предметной области ИС агент преобразуется в объекты диаграмм DFD и UML (рис. 1).
Если рассмотреть некоего программного агента в нотации DFD, то выполняемые функции агентом будут представлены в виде подмножества функций DFD, переменные представляющие наблюдаемые переменные или формируемые сообщения – представляют подмножества хранилищ на диаграмме DFD, а сам агент с точки зрения взаимодействия с пользователями и другими агентами – внешнюю сущность.
На рис. 1 показано, что агент представлен на DFD-диаграмме в виде Хранилища и Функции или Функций, которые он выполняет. На основе результатов структурного анализа строится UML-диаграмма прецедентов, на которой агенту сопоставляется определенная роль, и показаны связанные с ним прецеденты. Также эти данные могут быть использованы для формирования класса агента.
При проектировании ИС в архитектуре SOA или микросервисной отдельные сервисы могут быть рассмотрены в виде программных агентов, работающих автономно и/или взаимодействующих с конечными пользователями.
Рис. 1. Семантика перехода агента в объекты диаграмм
Рис. 2. DFD-диаграмма работы агента-микросервиса
Рассмотрим применение нашего метода при проектировании микросервиса, который реализует определенную функцию. При проектировании методов RESTful-API необходимо определить, какие данные необходимо предоставлять другим приложениям. В RESTful-API существует четыре возможности работы с информационными концептами: создать, удалить, получить и изменить. Пусть наш микросервис создает некоторую сущность и позволяет получить данные о ней, тогда у агента есть два метода: POST и GET.
Фрейм-концепт «Агент» будет иметь следующие свойства: идентификатор, название агента, цели агента, приоритет агента, количество входящих сообщений, количество исходящих сообщений и методы: сохранить ресурс (POST), получить информацию о ресурсе (GET). Если агент оперирует неким подмножеством информационных концептов, то соответствующие методы требуются для каждого из них.
Рассмотрим преобразование агента-микросервиса в объекты концептуальной модели предметной области (КМПО) ИС. Для хранения информации о ресурсах на DFD-диаграмме создается хранилище данных. На рис. 2 показана работа агента-микросервиса с ресурсом.
Рис. 3. UML-диаграмма последовательности работы агента-микросервиса
Таблица 1
Описание методов веб-сервиса BPsim.Web
|
Метод |
Название |
Пояснение |
|
POST |
/model |
Создать модель |
|
GET |
/model |
Получить данные обо всех моделях |
|
GET |
/model/{id} |
Получить данные о конкретной модели |
|
DELETE |
/model/{id} |
Удалить данные о конкретной модели |
|
PUT |
/model/{id} |
Изменить данные о конкретной модели |
|
POST |
/model/{id}/task |
Создать задачу на проведение имитационного эксперимента |
|
GET |
/task |
Получить данные обо всех задачах на выполнение имитации |
|
GET |
/task/{id} |
Получить данные о конкретной задаче на выполнение имитации |
|
DELETE |
/task/{id} |
Удалить данные о конкретной задаче на выполнение имитации |
|
GET |
/task/{id}/report |
Получить отчеты о результатах выполнения конкретной задачи на выполнение имитации |
Рис. 4. Архитектура сервиса имитационного моделирования бизнес-процессов
Для описания методов RESTful-API можно использовать спецификацию OpenAPI. При проектировании диаграммы последовательности можно описать тип метода и его параметры.
Для проверки адекватности метода в контексте проектирования ИС на основе микросервисов был разработан прототип сервиса имитационного моделирования BPsim.Web. Он представляет собой высоконагруженный веб-сервис, который позволяет работать с мультиагентными имитационными моделями бизнес-процессов.
На рис. 4 представлена архитектура сервиса имитационного моделирования.
Сервис управляет двумя концептами: модель имитационного моделирования и задача на выполнение имитации. Он получает команды из интерфейса интеграции (API) и, в зависимости от команды, получает или сохраняет данные в базу данных, выполняет внутренние преобразования и расчеты, запускает имитационный эксперимент. В ходе проектирования сервиса имитационного моделирования BPsim.Web были разработаны методы, представленные в табл. 1.
Объект модель БП имеет следующую структуру, представленную в табл. 2.
Таблица 2
Структура модели бизнес-процесса
|
Название атрибута |
Пояснение |
|
name |
Название модели |
|
resources |
Список ресурсов |
|
orders |
Список заявок |
|
nodes |
Список узлов (агенты, операции) |
Объекты ресурс, заявка и узел имеют следующую структуру: список свойств и их значений.
Разработанный прототип веб-сервиса позволяет осуществлять следующие действия через API:
− Создавать, получать, изменять и удалять имитационные модели.
− Планировать и запускать имитационные прогоны.
− Выгружать информацию о результатах имитационного моделирования.
Используя разработанный сервис, были построены две имитационные модели: модель отделов сопровождения телекоммуникационных систем цехов прокатки и модель взаимодействия цехов холодной и горячей прокатки. По каждой из моделей был проведен набор экспериментов и решена задача оптимизации.
Заключение
Предложенный авторами метод поддержки принятия решений при разработке информационных систем на основе мультиагентного подхода может быть использован при разработке веб-сервисов. Агент МППР подходит для описания веб-сервиса, доработка пакета BPsim позволит описывать API-методы сервиса. Разработанный прототип сервиса имитационного моделирования BPsim.Web в ходе проведения имитационных экспериментов показал свою работоспособность.