Агентный подход к разработке ДВ-УФО моделей

Системно-объектный ДВ-УФО метод предназначен для построения минимальных моделей социально-экономических систем (СЭС). Термин СЭС в контексте ДВ-УФО метода понимается в узком смысле, т.е. как совокупность юридических и физических лиц, взаимодействующих по поводу получения, перераспределения и переработки различных ресурсов. Минимальность модели определяется абстрагированием от всех технологических и иных аспектов, для учёта которых требуется представление ресурсов в натуральных единицах измерения. Существенными для целей ДВ-УФО моделирования являются только аспекты получения, перераспределения и переработки ресурсов, представленных в монетарном (денежном) формате. При этом ДВ-УФО модели позволяют эффективно решать задачи бизнес-планирования, инвестирования, проектного финансирования, являясь, по сути, цифровыми аналогами бизнес-планов [3].

На рис. 1 представлена ДВ-УФО модель СЭС, сформированной для строительства загородного коттеджа, реализованная с помощью исследовательской программы MoneyFlowPro.

Рис. 1. Модель СЭС

Приведённый на рис. 1 гипотетический пример СЭС хорошо иллюстрирует ДВ-УФО метод. В наглядной графической нотации представлены все члены СЭС, а также связи между ними. Важным является то, что в модели фиксируются не события перемещения ресурсов, а события оплаты этих ресурсов. Отделение в ДВ-УФО методе денежных ресурсов от материальных ресурсов и услуг, позволяет в ДВ-УФО модели фиксировать только события оплаты материальных ресурсов и услуг, сводя все ресурсные потоки к потокам траншей (потокам перемещения денежных средств). Стрелки на ДВ-УФО диаграмме показывают направления перемещения траншей (противоположные движению материальных ресурсов). Слева от ДВ-УФО диаграммы на рис. 1 показан каталог объектов, содержащий дополнительную информацию о СЭС. Это позволяет разгрузить ДВ-УФО диаграмму от текстовой информации и обеспечить простой доступ ко всем элементам модели.

Модель, представленную на рис. 1, действительно можно рассматривать как минимальную модель системы по реализации проекта строительства коттеджа, поскольку в ней отсутствуют все технологические аспекты строительства. Информация о материалах, требуемых для строительства, представлена в обобщённой денежной форме; работа строительной бригады также оценена не в натуральных единицах выполненных работ, а в денежном формате. При этом участниками СЭС являются юридические и физические лица, для которых определяются затраты и доходность участия в проекте. В данном примере затраты подрядчика составляют 3 у.е., а доход – 1 у.е., что обеспечивает рентабельность вложенных средств около 213% (см. рис. 2).

Рис. 2. Рентабельность вложения средств в проект подрядчиком

Приведённый пример показывает, что ДВ-УФО метод в своей базовой редакции, ориентированной на моделирование финансовых систем, вполне подходит для решения задач NPV и IRR анализа. Для использования в контексте цифровой экономики этого может оказаться недостаточно, и будет необходимо модернизировать базовую редакцию в различных направлениях.

Например, может потребоваться адаптировать базовую редакцию к условиям некоторой конкретной предметной области, чтобы специалисты этой области могли пользоваться не абстрактными терминами «репозиторий», «спонсор», «абсорбер», а привычными понятиями предметной области, в которой он работает.

Кроме того, поскольку ДВ-УФО метод ориентирован на практическое использование в контексте цифровой экономики, его нельзя рассматривать в отрыве от компьютерных информационных технологий. Таким образом, метод следует рассматривать в единстве с инструментарием компьютерной поддержки, т.е. как некоторую технологию. Следовательно, реализации ДВ-УФО модели с помощью компьютерных информационных технологий должно уделяться должное внимание.

Исследование данного вопроса показало, что парадигма объектно-ориентированного программирования (ООП) не предлагает прямой поддержки для расширения в различных направлениях базовой редакции ДВ-УФО метода. Дело в том, что понятие объекта в ООП существенно отличается от понятия системного объекта в УФО методе (Узел-Функция-Объект) [2], который использовался в качестве прототипа для ДВ-УФО метода. Точнее, ДВ-УФО метод может рассматриваться как проекция УФО метода в контекст цифровой экономики или как его специализация.

Системный объект УФО – это, прежде всего, поведение. Системный объект предназначен для выполнения запросов надсистемы, которые он реализует через взаимодействие с другими системными объектами одного с ним уровня. Суть взаимодействия состоит в обмене объектами нижнего яруса. Реализация взаимодействия осуществляется запросами к объектам нижнего яруса, для которых системный объект является надсистемой. Эта двойственность «Элемент-Система» позволяет моделировать сложные иерархические системы. При ДВ-УФО моделировании эта трёхмерная конструкция проецируется на плоскость, поскольку все взаимодействия сводятся к обмену траншами.

Объект в смысле ООП это – данные и операции над ними. Для выражения поведения объектов в ООП введены специальные конструкции: абстрактные классы в С++, интерфейсы в Java и С#. Хотя эти конструкции скорее из мира функционального программирования [5], чем ООП, они широко используются и интенсивно применяются при создании библиотек классов в перечисленных языках. Из сказанного следует, что не существует сколько-нибудь простого способа имитации поведения системного объекта в парадигме ООП.

Хотя в языки С++, Java и С# идёт интенсивное проникновение идей из функционального программирования, для адекватного представления системных объектов объектами из ООП необходимы концептуальные посредники между этими двумя мирами (предметными областями). Подход, основанный на программных агентах, предоставляет необходимые прокси.

Говоря об агентах (программных агентах), отметим, что почти все общие свойства агентов: автономность, адаптивность, коммуникативность, мобильность отражают различные аспекты поведения [1, с.243]. Наиболее важным для представления системных объектов является свойство коммуникативности, которое отражает способность программного агента взаимодействовать как с пользователем, использующим программу поддержки ДВ-УФО моделирования, так и с другими программными агентами. Однако, и другие свойства агентов также важны, особенно в контексте цифровой экономики.

Чтобы яснее понять задачи, которые должны решать программные агенты в контексте ДВ-УФО моделирования, вернёмся к примеру строительства загородного коттеджа (рис. 1). В данном примере поставщик материалов (для простоты он – один) моделируется объектом класса «Абсорбер». Такой выбор определяется тем, что задачи ДВ-УФО моделирования не включают расчёт доходности этого участника строительства. Если в процессе моделирование такая задача будет поставлена, то рамках ООП поменять класс поставщика материалов можно только удалив первоначальный объект класса «Абсорбер» и создав новый объект класса «Репозиторий». При этом, удалив первоначальный объект класса «Абсорбер», необходимо будет удалить и все транши получателем которых был удалённый объект. Вернее программа поддержки ДВ-УФО моделирования (подобная MoneyFlowPro) должна будет сделать это автоматически. Эти удалённые транши нужно будет восстановить, но уже не автоматически, что чревато дискредитацией модели и всего дальнейшего анализа, сделанного с её помощью.

Причина подобного положения дел в том, что основные языки ООП используют статическую типизацию, и программа поддержки ДВ-УФО моделирования не может обойти это ограничение. Между тем, ни оригинальный УФО метод, ни его специализация – ДВ-УФО метод никаких ограничений на тип системного объекта не налагают (его там просто нет). Тип появляется только при компьютерной реализации модели в парадигме ООП. Статичность типизации элементов ДВ-УФО модели исключает возможность слияния двух моделей в одну, поскольку один и тот же системный объект в разных моделях может быть по-разному типизирован.

Другая проблема, возникающая при реализации ДВ-УФО модели с помощью компьютерного инструментария поддержки ДВ-УФО моделирования, возникает при расширении текущей редакции на более широкую предметную область, когда необходимо в компьютерный инструментарий добавить поддержку новых типов объектов со специфическим поведением. В парадигме ООП необходимо будет в инструменты поддержки моделирования добавить классы для новых типов, и, что самое сложное, внести изменения в уже откомпилированный код. Другими словами, расширение предметной области требует изменения инструментария поддержки ДВ-УФО моделирования.

Прежде чем, рассматривать решение указанных проблем на основе агентного подхода, отметим, что в случае отсутствия необходимости расширения базовой редакции ДВ-УФО метода и внесения изменений в инструментарий компьютерной поддержки ДВ-УФО моделирования в рамках стандартного ООП возможна следующая очень эффективная реализация, основанная на следующих простых классах. Класс модели Model, класс транша Transh, класс узла Node и класс потока траншей Flow. Класс модели кроме наименования модели содержит коллекции узлов, потоков и траншей. Класс узла содержит имя и маркер тип узла (спонсор, репозиторий или абсорбер). Класс потока содержит ссылку на узел источник траншей, ссылку на узел приемник траншей, наименование потока. Класс транша содержит ссылку на поток, дату транша и сумму транша. Класс модели обеспечивает интерфейс пользователя и визуализацию. Остальные классы обеспечивают свою визуализацию (транши визуализируются во время своего создания, а в остальное время скрыты). На рис. 3 показан диалог создания объектов траншей.

Рис. 3. Диалог создания траншей

Функциональность всей программы инструментария ДВ-УФО моделирования, помимо классов библиотеки Qt 5.14, фактически обеспечивается одним классом модели, но такая архитектура очень проста и эффективна. Данная реализация инструментария поддержки базовой редакции ДВ-УФО метода, как будет показано далее, не вполне соответствует реальной структуре моделируемой СЭС, но является практически оптимальной в парадигме ООП.

Прежде чем обосновывать рациональность агентного подхода в вопросе цифровой реализации ДВ-УФО модели СЭС, отметим, что программный агент есть намного более сложный компонент программного кода, чем класс. Программный агент может состоять из множества взаимодействующих классов, которые все вместе обеспечивают требуемое поведение агента. В рамках ООП разработано большое количество готовых шаблонов программирования [4], позволяющих создавать тех или иных агентов (адаптивных, мобильных и т.д.). В вопросах адекватности модели важнее семантика, а не синтаксис. Сравним рассмотренную выше ООП реализацию инструментария поддержки ДВ-УФО моделирования с возможной агентной реализацией.

При обзоре ООП реализации отмечалось неполное соответствие ДВ-УФО модели и моделируемой СЭС. Это выражается, прежде всего, в том, что в ООП реализации транши, являющиеся реальными событиями перемещения денежных средств, для удобства реализации аналитических процедур собраны внутри класса модели. Тем самым происходит отчуждение траншей от источников их генерации, каковыми являются узлы, моделирующие реальных участников СЭС. Можно сказать, что удобный синтаксис доминирует над реальной семантикой. Указанное отделение источников траншей от самих траншей компенсируется в методах класса модели, но в случае расширения базовой редакции могут потребоваться дополнительные механизмы компенсации для сохранения адекватности модели. Если это не сделать, то постепенно произойдёт рассогласование между реалиями предметной области и семантикой ДВ-УФО модели.

Другой точкой рассогласования реальной СЭС и её ДВ-УФО моделью является размещения узлов внутри класса модели. Это не соответствует действительности. Узлы представляют собой реальных участников СЭС, но эти юридические или физические лица весьма условно можно считать частью СЭС. В рассмотренной ООП реализации это также компенсируется методами класса модели. Приведённые примеры показывают, что семантические проблемы не имеют полного решения с помощью синтаксических конструкций. Необходимо, используя агентный подход, устранять рассогласования в семантике предметной области и ДВ-УФО модели.

Приведём агентную реализацию ДВ-УФО модели. Отметим, что агент – это программный компонент, состоящий из некоторого количества согласованно взаимодействующих классов, обеспечивающих нужное поведение агента на основе подходящего шаблона программирования. Для агентной реализации ДВ-УФО модели нужны агенты Model, Node, Flow, Transh. В ООП реализации это были просто отдельные классы; сейчас это – более сложные программные компоненты. Агент Model содержит декларативные знания о моделируемой СЭС общего характера (наименование, сроки функционирования и т.п.), а также поддерживает интерфейс пользователя. Агент Model знает состав участников СЭС, но в отличие от ООП реализации содержит только ссылки на них. Участника СЭС представляет агент Node, содержащий информацию, идентифицирующую участника, а также знания о текущем балансе и, что самое главное, о своих обязательствах перед другими участниками. Агент Node инкапсулирует знания о своих обязательствах в коллекции агентов Flow, а знания о своих преференциях в коллекции ссылок на агентов Flow. Это вполне адекватно тому, что обязательства погашаются из собственных средств, а преференции это – чужие деньги, о которых известно всего лишь, что они должны поступить. Агент Flow инкапсулирует знания об источнике и приёмнике денежных средств, а также причину (основание) для их перемещения. Кроме того, агент Flow содержит коллекцию агентов Transh, содержащих информацию о дате события перемещения денежных средств и их количестве. Поведение всех агентов в базовой редакции вполне очевидно, а при расширении определяется семантикой предметной области.

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

Работа поддержана грантами РФФИ №№ 18-07-00310а, 18-07-00355а.