Показать метаданные Скрыть метаданные

(19)

(11)

2 438 161

(13)

(51)

МПК

G06F9/44(2006-01-01)

(21) (22)

Заявка

2009125011/08, 2007-11-30

(24)

Дата начала отсчета патента

2007-11-30

(22)

дата подачи заявки

2007-11-30

(45)

опубликовано

2011-12-27

(72)

авторы

Шамье ФадиЭдде Элиа

(73)

патентообладатели

Мюрекс С.А.С.

(56)

Документы, цитированные в отчете о поиске

US 5966072 А, 12.10.1999

ИНФРАСТРУКТУРА ГРАФООРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ НА ОСНОВЕ ПРОИЗВОДИТЕЛЕЙ С ПОДДЕРЖКОЙ СЦЕНАРИЕВ Российский патент 2011 года по МПК G06F9/44

Описание патента на изобретение RU2438161C2

ПЕРЕКРЕСТНАЯ ССЫЛКА НА РОДСТВЕННЫЕ ЗАЯВКИ

Отсутствует.

УРОВЕНЬ ТЕХНИКИ

Область техники, к которой относится изобретение

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

Уровень техники

Объектно-ориентированное программирование

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

Рефлексивный объектно-ориентированный язык - это язык программирования, который имеет определенный набор характеристик (к примеру, классы, объекты/экземпляры, наследование, рефлексия и т.д.), тогда как рефлексивный основанный на объектах язык иногда используется для того, чтобы помечать язык программирования, который имеет некоторый поднабор этих характеристик (к примеру, объекты). Для целей этого документа, фразы "объектно-ориентированный исходный код" и "объектно-ориентированный код" используются так, чтобы упоминаться как код, написанный на языке, который имеет такие характеристики (к примеру, код, написанный на рефлексивном объектно-ориентированном языке, код, написанный на рефлексивном основанном на объектах языке). Хотя процедурные языки, нерефлексивные объектно-ориентированные языки и нерефлексивные основанные на объектах языки - это языки программирования, которые типично не поддерживают такие характеристики, могут использоваться методики преобразования для того, чтобы предоставлять такие характеристики (к примеру, через эмуляцию) коду, надлежащим образом написанному на этих языках; и таким образом, данные методики преобразуют такие языки в рефлексивный объектно-ориентированный язык или рефлексивный основанный на объектах язык. (Эти методики не обязательно эмулируют все характеристики объектно-ориентированных или основанных на объектах языков, а могут эмулировать только те характеристики, которые представляют интерес для остальной части этого документа). Для целей этого документа, фразы "объектно-ориентированный исходный код" и "объектно-ориентированный код" также должны использоваться для того, чтобы упоминаться как такой преобразованный код процедурного, нерефлексивного объектно-ориентированного и нерефлексивного основанного на объектах языка. В качестве примера, а не ограничения, этот документ главным образом описывает объектно-ориентированный исходный код, написанный на рефлексивном объектно-ориентированном языке. Кроме этого, термины "объект" и "экземпляр" используются взаимозаменяемо в данном документе.

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

Когда программисты пишут программу с использованием объектно-ориентированного языка, результирующий код может концептуально рассматриваться как включающий в себя четыре основных типа кода. Первый тип включает в себя команды, которые оперируют с входным экземпляром(ами), чтобы предоставлять выходной экземпляр(ы) (упоминается в данном документе как код "преобразования"), типично написанные как методы (упоминается в данном документе как методы "преобразования"). Второй тип включает в себя команды создания экземпляра, которые инструктируют среде выполнения создавать экземпляры классов (упоминается в данном документе как код "создания экземпляра"). Третий тип включает в себя команды обработки свойств (упоминается в данном документе как код "подготовки данных"), чтобы активировать методы свойств (средства доступа, мутаторы и т.д.) вышеупомянутых экземпляров. Четвертый тип включает в себя последовательности команд, которые инструктируют упорядочение вызова метода с использованием соответствующих экземпляров (при этом соответствующие экземпляры включают в себя экземпляры, чтобы использовать как аргументы, экземпляры, которые должны быть использованы посредством методов экземпляров, и экземпляры метаклассов, используемые посредством методов классов), чтобы указывать то, какие методы преобразования каких экземпляров активировать, в каком порядке и с какими параметрами каких экземпляров в ответ на изменения, сделанные посредством кода подготовки данных (упоминается в данном документе как код "упорядочения вызовов вручную"). Код упорядочения вызовов вручную иногда пишется как методы, отдельные от методов преобразования, и тем самым код упорядочения вызовов вручную включает в себя последовательности команд вызова для методов преобразования. Программа типично выполняет итерации между кодом подготовки данных и кодом упорядочения вызовов вручную (который также может погружаться в код создания экземпляра), который, в свою очередь, активирует код преобразования (который также может погружаться в типы кода создания экземпляра и кода подготовки данных). Следует отметить, что это концептуальное представление программы и, таким образом, оно не должно считаться абсолютным относительно того, как трактовать программу.

Среда выполнения

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

Ранние среды выполнения, такие как FORTRAN, предоставляют такие признаки, как математические операции. Другие языки добавляют более сложные признаки - к примеру, сборка "мусора" в памяти, зачастую совместно с поддержкой объектов. Более современные языки имеют тенденцию иметь значительно большие среды выполнения со значительно большей функциональностью. Многие объектно-ориентированные языки также включают в себя систему, известную как "диспетчер" и "загрузчик классов". Виртуальная машина Java (JVM) является примером такой среды выполнения: она также интерпретирует или компилирует портативные двоичные программы Java (байт-код) в среде выполнения. Инфраструктура общеязыковой среды выполнения (CLR) является другим примером среды выполнения.

Инфраструктура программирования и выполнения

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

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

Код упорядочения вызовов вручную

Самые большие затраты, типично ассоциативно связанные с созданием приложения, заключают в себе отладку и/или оптимизацию кода упорядочения вызовов вручную. Для каждой возможности изменения данных, прикладной программист должен рассматривать ее результат и писать код упорядочения вызовов вручную, чтобы инструктировать активацию соответствующих методов преобразования соответствующих экземпляров в соответствующем порядке с соответствующими вводами. Примерные ошибки, делаемые прикладными программистами, включают в себя: 1) вызов соответствующих методов преобразования соответствующих экземпляров в неправильном порядке; 2) пренебрежение включением в программу команд, чтобы инструктировать активацию одного или более требуемых методов преобразования экземпляров в ответ на изменение некоторых данных; 3) включение в программу команд, чтобы инструктировать активацию ненужных методов преобразования экземпляров в ответ на изменение некоторых данных (к примеру, включение команд для того, чтобы активировать методы преобразования экземпляров, которые не затрагиваются изменением в данных), и т.д.

В качестве примера, одна методика формирования кода упорядочения вызовов вручную заключается в использовании шаблона наблюдателя (иногда называемого как "публикация и подписка"), чтобы наблюдать состояние экземпляра в программе. В шаблоне наблюдателя, один или более экземпляров (называемых наблюдателями или слушателями) регистрируются (или регистрируют себя), чтобы наблюдать событие, которое может генерироваться посредством наблюдаемого объекта (субъекта). Наблюдаемый экземпляр, который может генерировать событие, в общем, поддерживает совокупность зарегистрированных наблюдателей. Когда событие сгенерировано, каждый наблюдатель принимает обратный вызов от наблюдаемого экземпляра (наблюдаемый экземпляр активирует метод "уведомления" в зарегистрированных наблюдателях). Функция уведомления может передавать некоторые параметры (как правило, информацию о событии, которое происходит), которые могут использоваться посредством наблюдателей. Каждый наблюдатель реализует функцию уведомления и, как следствие, задает собственный характер изменения, когда уведомление возникает.

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

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

Перезаписываемый временный стек вызовов

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

Объектно-реляционное преобразование

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

Hibernate 3.0 - это решение объектно-реляционного преобразования для Java и CLR (Jboss® Inc, Атланта, Джорджия). Таким образом, Hibernate предоставляет инфраструктуру для преобразования объектно-ориентированной модели предметной области в традиционную реляционную базу данных. Его цель состоит в том, чтобы освобождать разработчика от некоторых стандартных связанных с сохраняемостью данных задач программирования. Hibernate берет на себя преобразование из классов в таблицы базы данных (и из объектно-ориентированных типов данных в типы SQL-данных), а также предоставление средств запрашивания и извлечения данных. Hibernate ориентирован на экземпляры и строит графы, представляющие взаимосвязи между экземплярами.

Принцип инверсии управления и инверсии зависимости

Инверсия управления, также известная как IOC, является принципом объектно-ориентированного программирования, который может использоваться для того, чтобы уменьшать связность (степень, в которой каждый программный модуль базируется на каждом другом модуле), внутренне присущую компьютерным программам. IOC также известен как принцип инверсии зависимости. В IOC класс X зависит от класса Y, если любое из следующего справедливо: 1) X имеет Y и вызывает его; 2) X - это Y; или 3) X зависит от некоторого класса Z, который зависит от Y (транзитивность). Стоит отметить, что X зависит от Y не подразумевает то, что Y зависит от X; если и то, и другое истина, это называется циклической зависимостью: X в таком случае не может использоваться без Y, и наоборот.

На практике, если объект x (класса X) вызывает методы объекта y (класса Y), то класс X зависит от Y. Зависимость инвертируется посредством представления третьего класса, а именно интерфейсного класса I, который должен содержать все методы, которые x может вызывать для y. Кроме этого, Y должен быть изменен так, что он реализует интерфейс I. X и Y теперь оба зависят от интерфейса I, и класс X более не зависит от класса Y (при условии, что x не создает экземпляр Y). Это устранение зависимости класса X от Y посредством представления интерфейса I, как говорят, является инверсией управления (или инверсией зависимости). Следует отметить, что Y может зависеть от других классов. Перед тем как преобразование применено, X зависел от Y, и таким образом X косвенно зависел от всех классов, от которых зависит Y. Посредством применения инверсии управления все эти косвенные зависимости разрушены. Новый представленный интерфейс I ни от чего не зависит.

Spring Framework - это инфраструктура приложений с открытым исходным кодом для платформы Java, которая использует IOC и инверсию зависимости. В частности, центральным в Spring Framework является контейнер инверсии управления, который предоставляет средство конфигурирования и управления объектами Java. Этот контейнер также известен как контейнер BeanFactory, ApplicationContext или Core. Примеры операций этого контейнера следующие: создание объектов, конфигурирование объектов, вызов методов инициализации и передача объектов в зарегистрированные объекты обратного вызова. Объекты, которые создаются посредством контейнера, также называются управляемыми объектами или объектами объектной модели JavaBeans. Типично контейнер конфигурируется посредством загрузки XML-файлов, которые содержат определения объектов объектной модели JavaBeans. Они предоставляют всю информацию, которая требуется для того, чтобы создавать объекты. Как только объекты созданы и сконфигурированы без возникновения состояний ошибки, они становятся доступными для использования. Объекты могут быть получены посредством поиска зависимости или введения зависимости. Поиск зависимости - это шаблон, где вызывающий объект запрашивает у контейнерного объекта объект с конкретным именем или конкретного типа. Введение зависимости - это шаблон, где контейнер передает объекты по имени в другие объекты либо через конструкторы, свойства или фабричные методы. Таким образом, Spring Framework ориентирована на память и строит графы, представляющие взаимосвязи между экземплярами.

Графические инструменты

JavadocTM - это инструментальное средство, которое синтаксически анализирует объявления и комментарии для документации в наборе исходных файлов Java и формирует соответствующий набор HTML-страниц, описывающих (по умолчанию) общедоступные и защищенные классы, вложенные классы (но не анонимные внутренние классы), интерфейсы, конструкторы, методы и поля (Sun Microsystems®, Inc, Санта-Клара, Калифорния). Javadoc может использоваться для того, чтобы формировать документацию по API (интерфейс прикладного программирования) или документацию по реализации для набора исходных файлов. Javadoc ориентирован на классы и методы и строит графы, представляющие взаимосвязи между комбинацией классов и их методами.

Другая система для проектирования приложений включает в себя графы объектов, анализируемые посредством интерпретатора для того, чтобы представлять и восстанавливать компьютерное приложение. Эта система использует заранее написанные программные классы, сохраненные в библиотеках кода, которые могут быть написаны так, чтобы следовать шаблонам проектирования, описанным в "Design Patterns" авторов Gamma et al, Addison Wesley 1995, "Patterns in Java" автора Grand, Wiley Computer Publishing 1998, и/или высокоуровневых инструментальных средств системы автоматизированной разработки программ (CASE). Более конкретно, некоторые такие классы основаны на шаблоне характера изменения наблюдателя. Заранее написанные библиотеки кода представляют узлы состояния приложения, логику обработки и поток данных системы между различными состояниями приложения (т.е. заранее написанными элементами данных приложения), так чтобы пользователю не требовалось писать, редактировать или компилировать код при создании приложения. Вместо этого пользователь вручную редактирует приложение в графическом пользовательском интерфейсе посредством редактирования визуальных объектов, ассоциативно связанных с узлом текущего состояния приложения, таких как данные в узле состояния приложения или процессы, выполняемые в узле состояния приложения. Затем на основе изменений, выполненных пользователем в узле текущего состояния приложения, интерпретатор отображает обновленное состояние приложения пользователю для состояния приложения, которое только что отредактировано. Система затем может переходить вдоль заданного пользователем ребра перехода к другому состоянию приложения, где пользователь необязательно может редактировать следующее состояние приложения или ребро перехода. Изменения на графе могут выполняться для экземпляров графа, которые реализуются посредством интерпретатора, в то время когда приложение выполняется.

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

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

Система, описанная выше, хотя использует визуальные представления приложений, также может использоваться как визуальное инструментальное средство программирования для задания и обновления реляционных баз данных. Система использует XML-описания визуального представления приложений. Инструментальное средство синтаксически анализирует и интерпретирует XML-описания, чтобы формировать эквивалентные схемы таблиц реляционных баз данных, а также изменения в них. Когда данные изменяются в визуальном представлении приложения, описание изменения сохраняется наряду с другими изменениями в файле журнала и затем обрабатывается как группа. Промежуточная программа (Java-приложение, оперирующее собственным потоком) выполняет транзакции между визуальным представлением приложения и реляционной базой данных. Java-приложение опрашивает (т.е. проверяет) журнал изменений узлов визуального представления (т.е. данных в базе данных), и если есть изменения, осуществляет изменения в базе данных. Таким образом, посредством изменения данных в визуальном представлении система обновляет базу данных. Аналогичное приложение является посредником между визуальным представлением приложения и базой данных, чтобы обрабатывать запросы на данные из базы данных.

Другая система для анализа программного обеспечения называется анализатором кодового дерева (CTA). CTA анализирует статический исходный код, написанный на языке объектно-ориентированного программирования. CTA формирует таблицу имен и дерево вызовов из статического исходного кода. Используя таблицу имен, CTA формирует диаграмму классов. Аналогично, используя дерево вызовов, CTA формирует диаграмму последовательности. Диаграмма классов иллюстрирует взаимосвязь между выбранным классом пользователя и классами, связанными с выбираемым пользователем классом. Диаграмма последовательности иллюстрирует последовательность, в которой вызываются различные методы. Используя как диаграмму классов, так и диаграмму последовательности, CTA формирует артефакт проектирования, представляющий статический исходный код. Когда пользователь модифицирует артефакт проектирования, CTA идентифицирует затрагиваемые части исходного кода с использованием схемы последовательности. Артефакт проектирования используется для сопровождения кода и/или разбора конструкции статического исходного кода.

Краткая сущность изобретения

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

Краткое описание чертежей

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

Фиг. 1B иллюстрирует примерные взаимосвязи между производителем 110A и родительским производителем 114A.1 согласно одному варианту осуществления изобретения;

Фиг. 1C иллюстрирует примерные взаимосвязи между производителем 110A и родительским производителем 112A.1 согласно одному варианту осуществления изобретения;

Фиг. 4A - это блок-схема, иллюстрирующая обнаружение и построение примерного графа производителей согласно одному варианту осуществления изобретения;

Фиг. 4B - это блок-схема, иллюстрирующая начальное выполнение графа производителей по фиг. 4A согласно одному варианту осуществления изобретения;

Фиг. 4C - это блок-схема, иллюстрирующая инкрементное выполнение графа производителей по фиг. 4B согласно одному варианту осуществления изобретения;

Фиг. 4D - это блок-схема, иллюстрирующая инкрементное выполнение графа производителей по фиг. 4B, после того как зависимый производитель 2 подменен, согласно одному варианту осуществления изобретения;

Фиг. 5D - это блок-схема, иллюстрирующая начальное выполнение графа производителей по фиг. 5A и/или повторное выполнение графа производителей по фиг. 5B или 5C согласно одному варианту осуществления изобретения;

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

Фиг. 7B - это блок-схема примерных производителей согласно одному варианту осуществления изобретения;

Фиг. 7E - это блок-схема примерных производителей согласно одному варианту осуществления изобретения;

Фиг. 7F - это блок-схема примерных зависимостей через использование UpwardDependency с производителем определения зависимостей согласно одному варианту осуществления изобретения;

Фиг. 7H иллюстрирует примерные графы производителей для стандартных производителей согласно одному варианту осуществления изобретения;

Фиг. 7I иллюстрирует один пример зависимостей производителя и производителей определения зависимостей для обнаружения, разрешения и построения графа производителей по фиг. 7H;

Фиг. 10 - это блок-схема примерной реализации согласно одному варианту осуществления изобретения;

Фиг. 11A - это блок-схема примера структуры 1092 отслеживания классов по фиг. 10 согласно одному варианту осуществления изобретения;

Фиг. 11B - это блок-схема примера структуры 1065 отслеживания классов по фиг. 10 согласно одному варианту осуществления изобретения;

Фиг. 11C - это блок-схема примера структуры 1060 графа(ов) производителей по фиг. 10 согласно одному варианту осуществления изобретения;

Фиг. 11D - это блок-схема примера структуры 1058 отслеживания методов по фиг. 10 согласно одному варианту осуществления изобретения;

Фиг. 12 - это блок-схема, иллюстрирующая дополнительные детали фиг. 10, чтобы поддерживать условные и подписные динамические зависимости производителя согласно одному варианту осуществления изобретения;

Фиг. 13B - это блок-схема производителей, иллюстрирующая примерную несокращенную объявленную, нединамическую (безусловную, неподписную) зависимость производителя согласно одному варианту осуществления изобретения;

Фиг. 13D - это блок-схема производителей, иллюстрирующая примерную несокращенную объявленную, условную, неподписную зависимость производителя согласно одному варианту осуществления изобретения;

Фиг. 13F - это блок-схема производителей, иллюстрирующая несокращенную объявленную, условную, неподписную зависимость производителя и сокращенную объявленную, условную, неподписную зависимость производителя согласно одному варианту осуществления изобретения;

Фиг. 13G иллюстрирует псевдокод объявлений зависимостей производителя для методов, использующих сокращенную объявленную, условную, неподписную зависимость производителя и сокращенную объявленную, безусловную, неподписную зависимость производителя, согласно одному варианту осуществления изобретения;

Фиг. 13H - это блок-схема производителей, иллюстрирующая примерную сокращенную объявленную, условную, неподписную зависимость производителя и сокращенную объявленную, безусловную, неподписную зависимость производителя согласно одному варианту осуществления изобретения;

Фиг. 13J - это блок-схема производителей, иллюстрирующая примерную сокращенную объявленную, нединамическую зависимость производителя, согласно одному варианту осуществления изобретения;

Фиг. 14A - это блок-схема примера журнала 1250 регистрации подписок по фиг. 12 согласно одному варианту осуществления изобретения;

Фиг. 14B - это блок-схема примерных производителей, иллюстрирующая безусловную зависимость производителя на основе поглощающей подписки согласно одному варианту осуществления изобретения;

Фиг. 14C - это блок-схема примерных производителей, иллюстрирующая безусловную зависимость производителя на основе прикрепляющей подписки согласно одному варианту осуществления изобретения;

Фиг. 15 - это блок-схема последовательности операций для создания новых экземпляров согласно одному варианту осуществления изобретения;

Фиг. 17 - это блок-схема последовательности операций для этапа 1650 по фиг. 16 согласно одному варианту осуществления изобретения.

Фиг. 18 - это блок-схема последовательности операций для этапа 1745 по фиг. 17 согласно одному варианту осуществления изобретения;

Фиг. 19 - это блок-схема последовательности операций для этапа 1630 по фиг. 16 согласно одному варианту осуществления изобретения;

Фиг. 20 - это блок-схема последовательности операций для этапов 1635 и 1670 по фиг. 16 согласно одному варианту осуществления изобретения;

Фиг. 21 - это блок-схема последовательности операций для подмены производителей согласно одному варианту осуществления изобретения;

Фиг. 22A - это часть блок-схемы последовательности операций для выполнения текущего графа(ов) производителей согласно одному варианту осуществления изобретения;

Фиг. 22B - это другая часть блок-схемы последовательности операций для выполнения текущего графа(ов) производителей согласно одному варианту осуществления изобретения;

Фиг. 23 - это блок-схема последовательности операций для этапа 2205 по фиг. 22 согласно одному варианту осуществления изобретения;

Фиг. 24 - это блок-схема последовательности операций для этапа 2225 по фиг. 22 согласно одному варианту осуществления изобретения;

Фиг. 25 - это блок-схема последовательности операций для этапа 2260 по фиг. 22 согласно одному варианту осуществления изобретения;

Фиг. 26 иллюстрирует альтернативный вариант осуществления изобретения, которое поддерживает сценарий;

Фиг. 28A-D иллюстрируют некоторые примерные графы производителей прикладной программы для различных сценариев;

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

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

Фиг. 31A иллюстрирует один примерный вариант осуществления структуры отслеживания классов;

Фиг. 31B иллюстрирует один примерный вариант осуществления структуры отслеживания экземпляров;

Фиг. 31C иллюстрирует один примерный вариант осуществления структуры графа производителей;

Фиг. 31D иллюстрирует один примерный вариант осуществления структуры отслеживания сценариев;

Фиг. 31E иллюстрирует один примерный вариант осуществления структуры отслеживания объектов сценариев;

Фиг. 31F иллюстрирует один примерный вариант осуществления списка воздействия;

Подробное описание изобретения

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

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

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

В последующем описании и формуле изобретения термины "связанный" и "соединенный" вместе с их производными могут использоваться. Следует понимать, что эти термины не служат в качестве синонимов друг для друга. Наоборот, в конкретных вариантах осуществления, "соединенный" может использоваться для того, чтобы указывать то, что два или более элементов находятся в прямом контакте друг с другом. "Связанный" может означать, что два или больше элемента находятся в прямом контакте. Тем не менее, "связанный" также может означать, что два или более элемента не находятся в прямом контакте друг с другом, но при этом по-прежнему совместно работают или взаимодействуют друг с другом.

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

Методики, показанные на чертежах, могут быть реализованы с использованием кода и данных, хранимых и выполняемых на одном или более компьютерах. Такие компьютеры сохраняют и передают (внутренне и с другими компьютерами по сети) код и данные, используя машиночитаемые носители, такие как компьютерные носители хранения (к примеру, магнитные диски; оптические диски; оперативное запоминающее устройство; постоянное запоминающее устройство; устройства флэш-памяти) и компьютерные среды связи (к примеру, электрическую, оптическую, акустическую или другую форму распространенных сигналов - к примеру, несущие волны, инфракрасные сигналы, цифровые сигналы и т.д.). Помимо этого, такие компьютеры типично включают в себя набор из одного или более процессоров, соединенных с одним или более других компонентов, таких как устройство хранения данных, определенное число пользовательских устройств ввода-вывода (к примеру, клавиатура и дисплей) и сетевое соединение. Соединение набора процессоров и других компонентов типично осуществляется через одну или более шин и мостов (также называемых как контроллеры шины). Устройство хранения данных и сетевой трафик, соответственно, представляют один или более компьютерных носителей хранения и компьютерных сред связи. Таким образом, устройство хранения данных данной компьютерной системы типично сохраняет код и данные для выполнения на наборе из одного или более процессоров этого компьютера. Конечно, одна или более частей варианта осуществления изобретения могут быть реализованы с использованием различных комбинаций программного обеспечения, микропрограммного обеспечения и/или аппаратных средств.

Обзор

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

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

В различных вариантах осуществления изобретения, производитель идентифицирует дополнительные факты. Например, хотя в некоторых вариантах осуществления изобретения производитель - это, по меньшей мере, экземпляр и метод, ассоциативно связанный с этим экземпляром, в других вариантах осуществления изобретения производитель - это класс, экземпляр этого класса и метод, ассоциативно связанный с этим экземпляром (к примеру, производитель может непосредственно включать в себя класс, экземпляр и метод; производитель может непосредственно включать в себя экземпляр и метод, при этом косвенно идентифицируя класс этого экземпляра через ссылку (к примеру, ссылку в экземпляре)). Хотя изобретение может использоваться в контексте кода, написанного на различных языках программирования (к примеру, объектно-ориентированного кода, написанного на рефлексивном объектно-ориентированном языке; объектно-ориентированного кода, написанного на рефлексивном основанном на объектах языке; кода, написанного на процедурном, нерефлексивном объектно-ориентированном, нерефлексивном основанном на объектах языке и преобразованного в рефлексивный код объектно-ориентированного языка), варианты осуществления изобретения описываются, в качестве примера, а не ограничения, в отношении рефлексивных языков объектно-ориентированного программирования и в отношении производителей, которые непосредственно включают в себя классы, экземпляры и методы. Кроме этого, хотя в одном варианте осуществления изобретения, метод производителя - это метод экземпляра (метод, который может использовать поля экземпляра в дополнение к любым вводам, принимаемым в качестве аргументов), альтернативные варианты осуществления изобретения также или альтернативно могут поддерживать метод производителя, являющийся методом класса (методы, которые принимают все вводы в качестве аргументов и/или используют независимые от экземпляров переменные) (если метод производителя - это метод экземпляра, то экземпляр этого производителя - это экземпляр класса; тогда как, если метод производителя - это метод класса, то экземпляр этого производителя - это экземпляр метакласса, представляющий класс).

Фиг. 1A - это блок-схема, иллюстрирующая взаимосвязь объявления зависимостей производителя для метода класса в объектно-ориентированном исходном коде с производителем, который включает в себя класс, данный экземпляр этого класса и метод этого класса, согласно одному варианту осуществления изобретения. На фиг. 1A показан объектно-ориентированный исходный код 100, включающий в себя класс 102, который, в свою очередь, включает в себя метод 104 и объявление 106 зависимостей производителя для метода 104. Конечно класс 102 типично должен включать в себя одно или более полей (не показаны) и дополнительных методов (не показаны). Помимо этого, объектно-ориентированный исходный код 100 типично должен включать в себя дополнительные классы.

В ходе выполнения экземпляр 108 класса 102 создается. Экземпляр 108 включает в себя данные полей класса 102. Помимо этого, создается экземпляр производителя 110, причем производитель 110 идентифицирует класс 102, экземпляр 108 класса 102 (который имеет ассоциативно связанный метод 104 класса 102) и метод 104 класса 102. Объявление 106 зависимостей производителя идентифицирует для среды выполнения набор из нуля или более производителей 112 (упоминаемых как дочерние производители производителя 110), который должен быть выполнен перед выполнением производителя 110. Другими словами, производитель 110 зависит от набора из нуля или более производителей 112. В дополнение или вместо потребления выводов набора производителя 112, производитель 110 может потреблять данные экземпляра 108. Помимо этого, производитель 110 предоставляет, по меньшей мере, один вывод, причем этот вывод может быть внутренним для экземпляра 108 (и тем самым модифицировать данные экземпляра 108) и/или может быть внешним; в любом случае, вывод производителя 110 может быть потреблен посредством набора из нуля или более других производителей 114 (упоминаемых как родительские производители производителя 110)). Как указано ранее и подробнее описано далее в данном документе, объявление 106 зависимостей производителя, в некоторых вариантах осуществления изобретения, также может идентифицировать для среды выполнения нуль или более производителей 114.

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

Объявление зависимостей производителя для данного метода идентифицирует в среде выполнения набор из нуля или более производителей, экземпляр которых должен создаваться и выполняться. В качестве примера, если объявление зависимостей производителя (к примеру, объявление 106 зависимостей производителя) для данного метода (к примеру, метода 104) идентифицирует зависимость производителя для данного производителя (причем этот данный производитель идентифицирует первый класс, первый экземпляр этого класса и первый метод этого первого класса) (к примеру, один из набора производителей 112), то объявление зависимостей производителя данного метода идентифицирует для среды выполнения, что первый экземпляр уже должен быть создан (если уже не создан) и что первый метод должен использоваться для того, чтобы создавать экземпляр данного производителя для первого экземпляра (в этих примерах, первый не означает местоположение или порядок).

При работе, когда в ходе выполнения данный набор из одного или более производителей обозначается как представляющий интерес и имеет объявленные зависимости производителя, среда выполнения: 1) автоматически формирует (обнаруживает, собирает и необязательно разрешает) набор из одного или более графов, которые могут быть многоуровневыми и могут иметь различные формы (к примеру, цепочку, дерево), из данного набора производителей, обозначенных как представляющие интерес нижележащим исходным производителям, на основе объявлений зависимостей производителя; и 2) упорядочивает выполнение производителей из набора графов, чтобы формировать вывод(ы) данного набора производителей, обозначенных как представляющие интерес. Таким образом, среда выполнения использует объявления зависимостей производителя для того, чтобы определять, какие методы с какими аргументами выполнять, на каких экземплярах, и когда в целях синхронизации.

Таким образом, зависимости производителя представляют упорядочение выполнения производителей для среды выполнения. Тем не менее, в дополнение к указанию упорядочения выполнения, зависимости производителя могут представлять различные взаимосвязи между вводом и выводом в различных вариантах осуществления изобретения. Например, различные варианты осуществления изобретения могут поддерживать одну или более из зависимостей аргументов производителя, зависимостей полей производителя и зависимостей упорядочения только производителей (зависимости упорядочения только производителей упоминаются в данном документе с сокращенными зависимостями упорядочения производителя). Хотя каждая из зависимостей аргументов производителя, зависимостей полей производителя и зависимостей упорядочения производителя представляет взаимосвязи упорядочения выполнения между производителями, зависимости аргументов и полей производителя дополнительно представляют данные, о которых среда выполнения знает. В частности, зависимость аргументов производителя инструктирует среде выполнения преобразовывать вывод дочернего производителя как входной параметр для родительского производителя, тогда как зависимость полей производителя указывает использование поля экземпляра. Независимо от взаимосвязи между вводом и выводом, представленной посредством зависимости производителя, надлежащее использование зависимостей производителя обеспечивает то, что производители, осуществляющие доступ к информации, упорядочиваются после производителей, которые оказывают воздействие на эту информацию.

Зависимости упорядочения могут использоваться для множества целей, включая обеспечение порядка выполнения между производителями, которые модифицируют данные таким образом, о котором среда выполнения не знает, и производителями, которые используют эти данные (дочерний производитель может записывать свои выводы способом, который требует того, чтобы метод родительского производителя включал код для того, чтобы осуществлять доступ к этому выводу (к примеру, метод, который влияет на окружение посредством воздействия на вывод, который не является обычным выводом производителя и, также, который не обнаруживается посредством среды выполнения - такой как метод, который задает глобальную переменную, которая задает поле в экземпляре, который не является выводом производителя, который влияет на внешний источник данных, и т.д.)). Таким образом, зависимость упорядочения отражает зависимость родительского производителя от дочернего производителя, но требует, чтобы выводы, которые должны предоставляться, если таковые имеются, от одного до другого, осуществлялись через написание кода (к примеру, кода в методе дочернего производителя, чтобы написать вывод в данный механизм (такой как задание глобальной переменной, воздействие на внешний источник данных, задание поля экземпляра, который не является выводом производителя, и т.д.), и кода в методе родительского производителя, чтобы считывать этот вывод из данного механизма). Таким образом, зависимости упорядочения дают возможность среде выполнения синхронизировать выполнение всех родительских производителей, которые базируются на выводе, который не может обнаруживать среда выполнения. Воздействие на источники (такие как глобальные переменные или внешние источники данных), о которых среда выполнения не знает, и считывание из этих источников является признаком, которого следует не допускать в производителях, где требуется поддержка сценариев.

В одном варианте осуществления изобретения, объявление зависимостей производителя для данного метода идентифицирует только прямые зависимости от производителей (например, прямые потомки (дочерние элементы), в отличие от косвенных потомков (внуки, правнуки и т.д.)). В этом варианте осуществления, каждое объявление зависимостей производителя предоставляет только один ярус или уровень производителей, выводы которых могут использоваться непосредственно посредством производителя, экземпляр которого создан из данного метода, оставляя обнаружение/сборку/разрешение дополнительных уровней графа(ов) производителей для обработки посредством среды выполнения других объявлений зависимостей производителя.

Примерные ключи

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

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

Использование ключей предоставляет множество признаков, в том числе: 1) отслеживание каждого объекта, идентифицированного посредством идентификаторов производителя (к примеру, отслеживание каждого класса, экземпляра и метода); 2) несколько родительских производителей (не имеющих сведений о своем взаимном существовании), чтобы соединяться с одним дочерним производителем на основе своих объявлений зависимостей производителя (которые указывают зависимости производителя с использованием ключей производителя); и т.д. В одном варианте осуществления изобретения, ключ экземпляра - это экземпляр класса (InstanceKey), содержащий два элемента: характер ключа экземпляра, указывающий, является ли ключевой идентификатор ссылкой на экземпляр или другой объект (такой как строка), и идентификатор ключа, который может быть ссылкой или на экземпляр, или на другой объект (такой как строка). Сохранение ссылки на экземпляр в ключе экземпляра освобождает программиста от изобретения имени, чтобы идентифицировать эти экземпляры.

Примерные взаимосвязи

В контексте вышеупомянутого пояснения, касающегося производителя, рассматриваемого как набор из нескольких идентификаторов (по одному идентификатору для каждого указанного дополнительного уровня степени детализации), в одном варианте осуществления изобретения, различные поддерживаемые взаимосвязи между производителем и его дочерними элементами и родительскими элементами - это взаимосвязи, при которых, по меньшей мере, один такой идентификатор отличается между производителем и его набором из нуля или более родительских производителей, и один такой идентификатор отличается между производителем и каждым из его набора из нуля или более дочерних производителей. Посредством предоставления нескольких примерных взаимосвязей, предположим, что первый производитель создает экземпляр, где первый производитель - это первый экземпляр первого класса и первый метод этого первого класса, и предположим, что объявление зависимостей производителя для этого первого метода идентифицирует в среде выполнения второго производителя как дочерний элемент, тогда второй производитель может быть: 1) первым экземпляром первого класса и вторым методом этого первого класса; 2) вторым экземпляром первого класса и вторым методом этого первого класса; или 3) вторым экземпляром первого класса и первым методом первого класса; или 4) экземпляром второго класса и методом этого второго класса. В таком случае первый производитель зависит от второго производителя - таким образом, представляя взаимосвязь между вводом и выводом первого производителя со вторым производителем. Различные взаимосвязи и комбинации этих взаимосвязей описываются ниже для одного варианта осуществления изобретения, который использует объектно-ориентированный язык и в котором производитель идентифицирует, по меньшей мере, класс, экземпляр и метод.

Фиг. 1B-1D иллюстрируют примерные взаимосвязи между данным производителем, его набором родительских производителей и его набором дочерних производителей согласно одному варианту осуществления изобретения. Фиг. 1B-1D показывают следующее: 1) определение 102A класса включает в себя методы 104A-C и объявления 106A-C зависимостей производителя для каждого из этих методов, соответственно; 2) определение 102B класса включает в себя методы 104D-E и объявления 106D-E зависимостей производителя для каждого из этих методов, соответственно; 3) определение 102C класса включает в себя метод 104F и объявление 106F зависимостей производителя для этого метода; 4) экземпляр 108A класса 102A; 5) производитель 110A, который идентифицирует класс 102A, экземпляр 108A и метод 104A; и 6) производитель 112A.1 и производитель 114A.1, соответственно, представляют один из набора производителей 112 и 114. Пунктирные линии с символами в прямоугольнике на них используются на фиг. 1B-1D для того, чтобы иллюстрировать примерные взаимосвязи. Таким образом, совокупность пунктирных линий с A в прямоугольнике на них представляет одну взаимосвязь. Взаимосвязи в фиг. 1B являются объединяемыми со взаимосвязями на фиг. 1C; также эти комбинации представляют комбинации взаимосвязей между родительскими производителями 114A и дочерними производителями 112A с производителем 110A. Дополнительно, фиг. 1D иллюстрирует некоторые дополнительные примерные комбинации взаимосвязей между родительскими производителями 114A и дочерними производителями 112A с производителем 110A.

Фиг. 1B иллюстрирует примерные взаимосвязи между производителем 110A и родительским производителем 114A.1 согласно одному варианту осуществления изобретения. Фиг. 1B дополнительно включает в себя экземпляр 108B. Набор производителей 114 идентифицируется посредством других объявлений зависимостей производителя другого метода(ов) того же класса, различных экземпляров того же класса и/или метода(ов) другого класса; и таким образом, каждый набор производителей 114 может быть: 1) из того же экземпляра, что и производитель 110A (экземпляра 108A класса 102A), и другого метода, ассоциативно связанного с этим экземпляром (проиллюстрированного посредством A в прямоугольнике на пунктирных линиях от экземпляра 108A к производителю 114A.1 и от метода 104B к производителю 114A.1); 2) из другого экземпляра класса 102A и другого метода, ассоциативно связанного с этим экземпляром (проиллюстрированного посредством B в прямоугольнике на пунктирных линиях от класса 102A к экземпляру 108B, от экземпляра 108B к производителю 114A.1 и от метода 104B к производителю 114A.1); 3) из экземпляра другого класса и метода, ассоциативно связанного с этим экземпляром (проиллюстрированного посредством C в прямоугольнике на пунктирных линиях от класса 102B к экземпляру 108B, от экземпляра 108B к производителю 114A.1 и от метода 104D к производителю 114A.1); или 4) из другого экземпляра класса 102A (чем экземпляр 108A) и того же метода (метода 104A) этого экземпляра (к примеру, с условной зависимостью - описанного далее в данном документе) (проиллюстрированного посредством D в прямоугольнике на пунктирных линиях от 102A класса к экземпляру 108B, от экземпляра 108B к производителю 114A.1 и от метода 104A к производителю 114A.1); дополнительно, где предусмотрено несколько производителей в наборе производителей 114, производители 114 сами могут быть частью того же экземпляра класса 102A, других экземпляров класса 102A, экземпляра другого класса, других экземпляров другого класса, и/или смеси вышеупомянутого.

Фиг. 1C иллюстрирует примерные взаимосвязи между производителем 110A и дочерним производителем 112A.1 согласно одному варианту осуществления изобретения. Фиг. 1C дополнительно включает в себя экземпляр 108C. Каждый набор производителей 112A может быть: 1) из того же экземпляра, что и производитель 110A (экземпляра 108A класса 102A), и другого метода, ассоциативно связанного с этим экземпляром (проиллюстрированного посредством E в прямоугольнике на пунктирных линиях от экземпляра 108A к производителю 112A.1 и от метода 104C к производителю 112A.1); 2) из другого экземпляра класса 102A и другого метода, ассоциативно связанного с этим экземпляром (проиллюстрированного посредством F в прямоугольнике на пунктирных линиях от класса 102A к экземпляру 108C, от экземпляра 108C к производителю 112A.1 и от метода 104C к производителю 112A.1); 3) из экземпляра другого класса и метода, ассоциативно связанного с этим экземпляром (проиллюстрированного посредством G в прямоугольнике на пунктирных линиях от класса 102C к экземпляру 108C, от экземпляра 108C к производителю 112A.1 и от метода 104F к производителю 112A.1); или 4) из другого экземпляра класса 102A (чем экземпляр 108) и того же метода (метода 104A) этого экземпляра (к примеру, с условной зависимостью - описанного далее в данном документе) (проиллюстрированного посредством H в прямоугольнике на пунктирных линиях от 102A класса к экземпляру 108C, от экземпляра 108C к производителю 112A.1 и от метода 104A к производителю 112A.1). Таким образом, каждый набор производителей 112A может иметь тот же экземпляр, что и производитель 110A, другой экземпляр класса 102A или экземпляр другого класса; дополнительно, где предусмотрено несколько производителей в наборе производителей 112A, производители 112A сами могут быть частью того же экземпляра класса 102A, других экземпляров класса 102A, того же экземпляра другого класса, других экземпляров другого класса и/или смеси вышеупомянутого.

Фиг. 1D иллюстрирует некоторые дополнительные примерные комбинации взаимосвязей родительских производителей 114 и дочерних производителей 112 с производителем 110A согласно одному варианту осуществления изобретения. Фиг. 1D дополнительно включает в себя экземпляр 108B и экземпляр 108C. Комбинации по фиг. 1D показаны в таблице 1 ниже:

Таблица 1 Символ в прямоуголь-нике Пунктирные линии для родительского производителя 114A.1 от Пунктирные линии для дочернего производителя 112A.1 от I От экземпляра 108A к производителю 114A.1 и от метода 104B к производителю 114A.1 От экземпляра 108A к производителю 112A.1 и от метода 104B к производителю 112A.1 J От экземпляра 108A к производителю 114A.1 и от метода 104B к производителю 114A.1 От класса 102A к экземпляру 108C, от экземпляра 108C к производителю 112A.1 и от метода 104B к производителю 112A.1 K От класса 102A к экземпляру 108B, от экземпляра 108B к производителю 114A.1 и от метода 104B к производителю 114A.1 От экземпляра 108A к производителю 112A.1 и от метода 104B к производителю 112A.1 L От класса 102B к экземпляру 108B, от экземпляра 108B к производителю 114A.1 и от метода 104E к производителю 114A.1 От класса 102B к экземпляру 108B, от экземпляра 108B к производителю 112A.1 и от метода 104E к производителю 112A.1 M От класса 102B к экземпляру 108B, от экземпляра 108B к производителю 114A.1 и от метода 104E к производителю 114A.1 От класса 102B к экземпляру 108C, от экземпляра 108C к производителю 112A.1 и от метода 104C к производителю 112A.1 N От класса 102A к экземпляру 108B, от экземпляра 108B к производителю 114A.1 и от метода 104A к производителю 114A.1 От класса 102A к экземпляру 108C, от экземпляра 108C к производителю 112A.1 и от метода 104A к производителю 112A.1 O От класса 102A к экземпляру 108B, от экземпляра 108B к производителю 114A.1 и от метода 104A к производителю 114A.1 От класса 102A к экземпляру 108B, от экземпляра 108B к производителю 112A.1 и от метода 104A к производителю 112A.1 P От экземпляра 108A к производителю 114A.1 и от метода 104B к производителю 114A.1 От класса 102A к экземпляру 108C, от экземпляра 108C к производителю 112A.1 и от метода 104A к производителю 112A.1 Q От класса 102A к экземпляру 108B, от экземпляра 108B к производителю 114A.1 и от метода 104A к производителю 114A.1 От класса 102A к экземпляру 108B, от экземпляра 108B к производителю 112A.1 и от метода 104B к производителю 112A.1 R От класса 102B к экземпляру 108B, от экземпляра 108B к производителю 114A.1 и от метода 104D к производителю 114A.1 От класса 102B к экземпляру 108B, от экземпляра 108B к производителю 112A.1 и от метода 104E к производителю 112A.1

Фиг. 1E иллюстрирует, что различные экземпляры одного класса могут иметь производители на основе таких же и/или других методов согласно одному варианту осуществления изобретения. Фиг. 1E показывает, что: 1) определение 102A класса включает в себя методы 104A-C и объявления 106A-C зависимостей производителя для каждого из этих методов, соответственно; 2) экземпляр 108A и экземпляр 108B появляются из класса 102A; 3) производитель 110A является методом 104A экземпляра 108A класса 102A; 4) производитель 110B является методом 104B экземпляра 108A класса 102A; 5) производитель 110C является методом 104A экземпляра 108B класса 102A; и 6) производитель 110D является методом 104C экземпляра 108B класса 102A. Помимо этого, фиг. 1D показывает, что: 1) объявление 106A зависимостей производителя для метода 104A идентифицирует в среде выполнения дочерних производителей как производителя 110A, так и производителя 110C; 2) объявление 106B зависимостей производителя для метода 104B идентифицирует в среде выполнения дочернего производителя для производителя 110B; и 3) объявление 106C зависимостей производителя для метода 104C идентифицирует в среде выполнения дочернего производителя для производителя 110D.

Примерные среды выполнения

Фиг. 2 - это блок-схема, иллюстрирующая повторное использование среды выполнения со средствами поддержки графоориентированного программирования на основе производителей согласно одному варианту осуществления изобретения. На фиг. 2 несколько объектно-ориентированных прикладных программ (объектно-ориентированный код приложения с объявлениями 210A-I зависимостей производителя) выполняются посредством одной среды выполнения со средствами 220 поддержки графоориентированного программирования на основе производителей.

Фиг. 3A - это блок-схема, иллюстрирующая среду выполнения со средствами поддержки графоориентированного программирования на основе производителей согласно одному варианту осуществления изобретения. На фиг. 3A среда выполнения со средствами 335 поддержки графоориентированного программирования на основе производителей включает в себя модуль 340 автоматического формирования графа производителей и модуль 345 выполнения графа производителей. Среда 335 выполнения должна выполнять объектно-ориентированный исходный код и таким образом включает в себя дополнительные не показанные модули.

Помимо этого, фиг. 3A показывает объявления зависимостей производителя для методов в объектно-ориентированном исходном коде 320, текущий набор из одного или более производителей, выводы которых представляют интерес 325 (также упоминаемых здесь как текущие выбранные интересующие производители) и выводы исходных производителей 330 (описанные далее в данном документе). Модуль 340 автоматического формирования графа производителей принимает объявления 320 зависимостей производителя и текущий набор интересующих производителей 325.

Модуль 340 автоматического формирования графов производителей пытается обнаруживать на основе объявлений зависимостей производителя дочерние производители с выводами, которые вносят вклад непосредственно и косвенно во ввод текущих выбранных интересующих производителей (и в некоторых вариантах осуществления изобретения, которые поддерживают восходяще объявляемые зависимости родительских производителей), и собирает набор из одного или более текущих графов производителей, представляющих зависимость этих производителей друг от друга из текущих выбранных интересующих производителей, через любые обнаруженные производители, которые являются неисходными производителями, для тех из обнаруженных производителей, которые являются исходными производителями. Текущие графы производителей сохраняются в структуре 380 графа(ов) производителей. Хотя варианты осуществления изобретения позволяют сохранять и обрабатывать граф(ы) производителей как совокупность графов, другие варианты осуществления изобретения сохраняют и обрабатывают граф(ы) производителей как совокупность производителей, которые связаны друг с другом, чтобы формировать граф(ы) (в противоположность совокупности графов), чтобы упрощать объединение и расщепление графов производителей. В качестве примера, а не ограничения, варианты осуществления изобретения, которые сохраняют и обрабатывают граф(ы) производителей как совокупность производителей, описываются в данном документе.

Модуль 345 выполнения графа производителей принимает текущий граф(ы) производителей от модуля 340 автоматического формирования графов и выводов исходных производителей 330 и выполняет производителей из текущего графа(ов) производителей, чтобы определять текущий вывод текущих выбранных интересующих производителей. Модуль 345 выполнения графа производителей кэширует текущие выводы производителей в структуре 380 графа(ов) производителей, как проиллюстрировано посредством кэширования 384 выводов производителя.

Кэширование выводов производителя для графа производителей в ходе выполнения предоставляет возможность синхронизации. Например, подходящее время для того, чтобы выполнять родительский производитель, который зависит от нескольких дочерних производителей, - это время после того, как все несколько дочерних производителей выполнены; другими словами, излишне (и, в некоторых случаях, невозможно) выполнять родительский производитель каждый раз, когда один из его дочерних производителей завершил выполнение. Кэширование выводов производителя предоставляет возможность не только откладывания выполнения родительского производителя до тех пор, пока все его дочерние производители не выполнены, оно также предоставляет возможность определения подходящего времени для выполнения родительского производителя - когда все дочерние производители выполнены и их выводы кэшированы. Таким образом, среда выполнения принимает это решение синхронизации для программиста посредством проверки состояния выполнения их дочерних производителей; другими словами, такая синхронизация автоматизирована (программист не должен включать отдельный исходный код, который определяет подходящее время для того, чтобы идентифицировать экземпляр и выполнять данный метод, ассоциативно связанный с этим экземпляром над этим экземпляром). В качестве другого примера, если несколько родительских производителей зависят от одного дочернего производителя, а также от других различных дочерних производителей, подходящее время для того, чтобы выполнять каждый из этих нескольких родительских производителей типично является различным; среда выполнения автоматически определяет подходящее время для того, чтобы выполнять каждый из этих нескольких родительских производителей в зависимости от доступности выводов своего набора дочерних производителей.

Как подробнее описано далее в этом документе, поскольку некоторые части графа производителей не могут в данный момент поддаваться обнаружению вследствие динамических зависимостей производителя, модуль 340 автоматического формирования графа производителей "пытается" обнаруживать и собирать весь граф производителей, но первоначально не может иметь возможности завершать весь граф производителей, пока некоторые производители не выполнятся. По сути, модуль 345 выполнения графа производителей может активировать модуль 340 автоматического формирования графа производителей с необходимыми выводами производителя в ходе выполнения текущего графа производителей, чтобы завершать все неразрешенные оставшиеся части текущего графа производителей (это проиллюстрировано на фиг. 3A посредством пунктирной линии со стрелками от модуля 345 выполнения графа производителей к модулю 340 автоматического формирования графа производителей; пунктирная линия со стрелками используется, поскольку такая поддержка является необязательной).

Фиг. 4A - это блок-схема, иллюстрирующая обнаружение и построение примерного графа производителей согласно одному варианту осуществления изобретения. Фиг. 4A показывает то, что текущий набор интересующих производителей состоит из производителя 1. На основе производителя 1 и его объявления зависимостей производителя производитель 2 и производитель 3 обнаруживаются. Другими словами, объявление зависимостей производителя для производителя 1 идентифицирует, что ввод в производитель 1 требует выполнения производителя 2 и производителя 3. По сути, производитель 1 является зависимым производителем (производителем, который имеет одну или более зависимостей производителя). Фиг. 4A также показывает то, что хотя производитель 3 является независимым производителем (производителем, который не имеет зависимостей производителя и тем самым является исходным производителем), производитель 2 не является им. Как результат, на основе объявления зависимостей производителя для производителя 2, обнаруживаются производитель 4 и производитель 5. На фиг. 2A, производитель 4 и производитель 5 являются независимыми производителями (и тем самым исходными производителями).

Фиг. 4B - это блок-схема, иллюстрирующая начальное выполнение графа производителей по фиг. 4A согласно одному варианту осуществления изобретения. На фиг. 4B, изогнутые линии со стрелками иллюстрируют выполнение одного производителя, чтобы формировать вывод, который предоставляется в качестве ввода в другой производитель. Как показано на фиг. 3A, вывод исходных производителей 330 предоставляется в модуль 345 выполнения графа производителей; наоборот, выводы зависимых производителей 1-2 определяются посредством выполнения этих производителей так, как показано на фиг. 4B. Таким образом, на фиг. 4B происходит следующее: 1) вывод исходного производителя 4 и исходного производителя 5 предоставляется в зависимый производитель 2; 2) зависимый производитель 2 выполняется; 3) выводы зависимого производителя 2 и исходный производитель 3 предоставляются в производитель 1; и 4) производитель 1 выполняется, и его вывод предоставляется в качестве интересующего текущего вывода. Стоит отметить, что граф производителей по фиг. 4B направляется по данным в том смысле, что данные протекают от одного производителя к другому производителю вверх по графу.

Таким образом, объявления 320 зависимостей производителя ограничивают возможные графы производителей, которые могут быть сформированы, тогда как в настоящий момент выбранный набор интересующих производителей 325 идентифицирует начальный узел(лы) текущего графа производителей, который должен быть сформирован. Из этих двух предпосылок, модуль 340 автоматического формирования графов производителей обнаруживает и строит граф производителей. Обнаружение и построение автоматизированы в том, что в модуль 340 автоматического формирования графов производителей не предоставляется граф производителей (к примеру, он не должен быть вручную идентифицирован программистом) или даже список производителей, которые должны быть на графе производителей. Наоборот, модуль 340 автоматического формирования графов производителей синтаксически анализирует объявление(я) зависимостей производителя текущего выбранного набора интересующих производителей, чтобы обнаруживать их дочерних производителей (а в некоторых вариантах осуществления изобретения, которые поддерживают восходяще объявляемые зависимости, и родительских производителей), затем синтаксически анализирует объявления зависимостей производителя этих обнаруженных производителей и т.д. вниз к исходным производителям (в некоторых вариантах осуществления изобретения, описанных далее в данном документе, это может осуществляться с помощью модуля 345 выполнения графа производителей). В случае, если граф производителей - это дерево, текущий выбранный интересующий производитель является в типичном варианте корневым узлом, и объявления зависимостей производителя синтаксически анализируются до тех пор, пока концевые узлы (исходные производители) не обнаружены.

Подмененные производители и инкрементное выполнение

Фиг. 3B - это блок-схема, иллюстрирующая среду выполнения со средствами поддержки графоориентированного программирования на основе производителей, которая также поддерживает инкрементное выполнение и выводы подмененных производителей согласно одному варианту осуществления изобретения. Следует понимать, что инкрементное выполнение и выводы подмененных производителей являются независимыми необязательными признаками, и таким образом различные варианты осуществления изобретения могут реализовать один из них или оба.

На фиг. 3B, среда выполнения со средствами 360 поддержки графоориентированного программирования на основе производителей включает в себя модуль 365 автоматического формирования графов производителей, модуль 370 выполнения графа производителей и модуль 390 вывода подмененных производителей. Среда 360 выполнения должна выполнять объектно-ориентированный исходный код и таким образом включает в себя дополнительные не показанные модули.

Помимо этого, фиг. 3B показывает объявления зависимостей производителя для методов в объектно-ориентированном исходном коде 320, текущий набор из одного или более производителей, выводы которых представляют интерес 325 (также упоминаемых в данном документе как текущие выбранные интересующие производители), и вывод исходных производителей 350. Вывод исходных производителей 350 включает в себя выводы независимых производителей, заданные в исходном коде 352 (к примеру, константы, значения по умолчанию и т.д.), и текущие выводы 354 подмененных производителей (выводы независимых производителей и/или зависимых производителей, выводы которых в настоящий момент подменены).

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

Модуль 390 вывода подмененных производителей принимает выводы 354 подмененных производителей (которые идентифицируют, какие производители подменены и на какие выходные значения они подменены). В одном варианте осуществления изобретения, производители могут быть классифицированы как производители свойств или производители методов. Производители свойств - это производители, основанные на методах со свойствами (к примеру, получить и задать). Производители методов - это производители, основанные на методах без свойств. Модуль 390 вывода подмененных производителей включает в себя модуль 392 вывода подмененных производителей свойств для подмененных производителей свойств и модуль 394 вывода подмененных производителей методов для подмененных производителей методов. Модуль 392 вывода подмененных производителей свойств инструктирует сохранение подмененного значения в кэшировании 384 выводов производителя и в данных экземпляра, тогда как модуль 394 вывода подмененных производителей методов инструктирует сохранение подмененного значения в кэшировании 384 выводов производителя. В зависимости от варианта осуществления изобретения, эта причинно-следственная зависимость может быть прямой или косвенной. Фиг. 3B иллюстрирует косвенную причинно-следственную зависимость с помощью журнала 396 регистрации подмены, который собирает вывод модуля 390 вывода подмененных производителей и который используется посредством модуля 370 выполнения графа производителей. В целях оптимизации журнал 396 регистрации подмены предоставляет возможность отсрочки подмен, чтобы собирать несколько подмен для обработки в пакетном режиме.

Аналогично модулю 340 автоматического формирования графов производителей, модуль 365 автоматического формирования графов производителей: 1) принимает объявления 320 зависимостей производителя и текущий набор интересующих производителей 325; и 2) пытается обнаруживать на основе объявлений зависимостей производителя дочерние производители с выводами, которые вносят вклад непосредственно и косвенно во ввод текущих выбранных интересующих производителей (и в некоторых вариантах осуществления изобретения, которые поддерживают восходяще объявляемые зависимости, родительских производителей), и собирает набор из одного или более текущих графов производителей, представляющих входную зависимость этих производителей друг от друга из текущих выбранных интересующих производителей, через любые обнаруженные неисходные производители, для тех из обнаруженных производителей, которые являются исходными производителями (независимым производителям и текущим подмененным производителям). Граф(ы) производителей сохраняются в структуре 380 графа(ов) производителей.

Аналогично модулю 345 выполнения графа производителей, модуль 370 выполнения графа производителей принимает текущий граф производителей от модуля 365 автоматического формирования графов и выводов исходных производителей 350 и выполняет производителей из текущего графа производителей, чтобы определять текущий вывод текущих выбранных интересующих производителей. Модуль 370 выполнения графа производителей кэширует текущие выводы производителей в структуре 380 графов производителей, как проиллюстрировано посредством кэширования 384 выводов производителя.

Как ранее описано, кэширование выводов производителя в ходе выполнения предоставляет возможность синхронизации (к примеру, отдельный исходный код не обязательно должен быть написан для того, чтобы определять, когда производитель 2 по фиг. 4B должен быть выполнен, а вместо этого среда выполнения принимает данное решение по синхронизации для программиста посредством проверки доступности необходимых выводов в кэшировании 384 выводов производителя; другими словами, такая синхронизация автоматизирована). Помимо этого, данное кэширование 384 выводов производителя используется для инкрементного выполнения. Более конкретно, после того как граф производителей первоначально сформирован и выполнен, подмена производителя в текущем графе производителей требует некоторого уровня повторного выполнения. Хотя некоторые варианты осуществления изобретения просто повторно выполняют весь граф, альтернативные варианты осуществления изобретения поддерживают инкрементное выполнение (повторно выполняя только те части графа производителей, которые затрагиваются подменой). Некоторые примерные варианты осуществления, которые поддерживают инкрементное выполнение, используют маркировку 382 инкрементного выполнения в структуре 380 графа(ов) производителей для того, чтобы помогать определять то, какие производители требуют повторного выполнения. Таким образом, поддержание графа производителей упоминается как модификация связей графа(ов) производителей по мере необходимости через несколько выполнений, чтобы сохранять их текущими (актуальными), тогда как инкрементное выполнение упоминается как поддержание графа(ов) производителей, так и как использование текущего (актуального) графа(ов) производителей для того, чтобы повторно выполнять только те части графа производителей, которые затрагиваются подменой.

Аналогично фиг. 3A, имеется пунктирная линия со стрелками от модуля 370 выполнения графа производителей к модулю 365 автоматического выполнения графа производителей, чтобы представлять необязательную поддержку динамических зависимостей. Следует отметить, что динамические зависимости могут изменяться в ходе повторного выполнения графа производителей.

Фиг. 4C - это блок-схема, иллюстрирующая инкрементное выполнение графа производителей по фиг. 4B согласно одному варианту осуществления изобретения. На фиг. 4C вывод производителя 5 явно модифицирован, но выводы производителя 3 и производителя 4 не модифицированы. На основе отслеживания зависимостей между выводом и вводом на графе производителей и того, что только вывод производителя 5 явно модифицирован, определяется то, что только производитель 2 и производитель 1 затрагиваются посредством этой модификации. Как результат, определение обновленного вывода производителя 1 требует только повторного выполнения производителя 2 и производителя 1 с новым выводом производителя 5 и предыдущими выводами производителя 4 и производителя 3. Это частичное повторное выполнение графа производителей проиллюстрировано на фиг. 4C посредством изогнутых линий со стрелками от производителя 5 к производителю 2 и от производителя 2 к производителю 1, но не от производителя 4 к производителю 2 или от производителя 3 к производителю 1. Отсутствие изогнутых линий со стрелками от производителя 4 к производителю 2 и от производителя 3 к производителю 1 должно указывать не то, что выводы производителя 3 и производителя 4 не требуются, а скорее то, что производитель 3 и производитель 4 не должны повторно выполняться, если их предыдущий вывод доступен (к примеру, кэширован из предыдущего выполнения графа производителей).

Относительно простой пример по фиг. 4C иллюстрирует то, что может быть экономия ресурсов обработки в результате инкрементного выполнения. Такая экономия зависит от ряда факторов (к примеру, числа производителей, которые не должны повторно выполняться, объема обработки, которую эти производители потребовали бы, и т.д.). Хотя проиллюстрирован один вариант осуществления изобретения, который выполняет инкрементное выполнение, альтернативные варианты осуществления могут быть реализованы по-другому (к примеру, альтернативный вариант осуществления может повторно выполнять всех производителей в ответ на модификацию).

Фиг. 4D - это блок-схема, иллюстрирующая инкрементное выполнение графа производителей по фиг. 4B после того, как зависимый производитель 2 подменен, согласно одному варианту осуществления изобретения. На фиг. 4D вывод производителя 2 явно модифицирован, но вывод производителя 3 не модифицирован. На основе графа производителей и того, что только вывод производителя 2 явно модифицирован, определяется то, что только производитель 1 затрагивается этой модификацией. Как результат, определение обновленного вывода производителя 1 требует только повторного выполнения производителя 1 с подмененным выводом производителя 2 и предыдущим выводом производителя 3. Это частичное повторное выполнение графа производителей проиллюстрировано на фиг. 4D посредством изогнутой линии со стрелками от производителя 2 к производителю 1, но не от производителя 4 и 5 к производителю 2 или от производителя 3 к производителю 1.

Фиг. 4E - это блок-схема, иллюстрирующая инкрементное выполнение графа производителей по фиг. 4B, после того как зависимый производитель 2 подменен, а независимый исходный производитель 3 модифицирован, согласно одному варианту осуществления изобретения. На основе графа производителей и того, что только выводы производителя 2 и производителя 3 модифицированы, определяется то, что только производитель 1 затрагивается этой модификацией. Как результат, определение обновленного вывода производителя 1 требует только повторного выполнения производителя 1 с подмененным выводом производителя 2 и модифицированным выводом производителя 3. Это частичное повторное выполнение графа производителей проиллюстрировано на фиг. 4E посредством изогнутой линии со стрелками от производителей 2 и 3 к производителю 1, но не от производителей 4 и 5 к производителю 2.

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

Построение и выполнение графа производителей

Различные варианты осуществления изобретения могут быть реализованы так, чтобы обнаруживать и строить граф производителей в различной степени (к примеру, строить граф производителей до тех пор, пока все пути от корневого узла не завершаются независимыми производителями (в этом случае конечные узлы графа производителей являются независимыми производителями с возможностью всех подмененных производителей быть промежуточными узлами); строить граф производителей до тех пор, пока каждый путь от корневого узла не завершается подмененным производителем или независимым производителем, какой из них достигается первым (в этом случае каждый конечный узел графа производителей является либо независимым производителем, либо подмененным производителем)).

"Производители начала выполнения" упоминаются как производители графа производителей, с которых начинается данное выполнение графа производителей. Для начального выполнения графа производителей различные варианты осуществления могут начинаться с различных производителей (к примеру, в вариантах осуществления изобретения, которые собирают граф производителей до тех пор, пока все пути от корневого узла не завершаются независимыми производителями, выполнение может начинаться от конечных узлов (которые должны быть независимыми производителями), от исходных производителей (которые должны включать в себя узлы независимых производителей и все узлы подмененных производителей), от поднабора исходных производителей, состоящего из комбинации всех независимых производителей, по меньшей мере, с одним путем между ними и корневым производителем, который не включает в себя подмененный производитель, и всех подмененных производителей, или от поднабора исходных производителей, состоящего из комбинации всех подмененных производителей без каких-либо потомков, которые подменены, и всех независимых производителей, по меньшей мере, с одним путем между ними и корневым производителем, который не включает в себя подмененный производитель; в вариантах осуществления изобретения, где граф производителей в рамках подмененных производителей не строится, если и до тех пор, пока подмена такого производителя не отменена, выполнение может начинаться с конечных узлов (которые могут быть независимыми производителями и/или подмененными производителями) и т.д.).

Для последующего выполнения графа производителей различные варианты осуществления могут начинаться от различных производителей (к примеру, от независимых производителей графа производителей (к примеру, в вариантах осуществления изобретения, которые не поддерживают инкрементное выполнение); от исходных производителей графа производителей (к примеру, в вариантах осуществления изобретения, которые не поддерживают инкрементное выполнение); от поднабора исходных производителей, который состоит из тех исходных производителей, которые подменены и/или добавлены начиная с последнего выполнения (к примеру, в вариантах осуществления изобретения, которые поддерживают инкрементное выполнение); из исходных производителей, которые подменены и/или добавлены начиная с последнего выполнения, от комбинации всех таких подмененных производителей без каких-либо потомков, которые подменены, и всех таких добавленных производителей, по меньшей мере, с одним путем между ними и корневым производителем, который не включает в себя подмененный производитель (к примеру, в вариантах осуществления изобретения, которые поддерживают инкрементное выполнение); и т.д.). В качестве примера, а не ограничения, ниже описаны варианты осуществления изобретения, которые выполняют следующее: 1) не строят граф производителей под подмененными производителями, если и до тех пор, пока подмена таких производителей не отменена; 2) для начального выполнения графа производителей, начинают выполнение от конечных узлов (которые могут быть независимыми производителями и/или подмененными производителями); 3) реализуют инкрементное выполнение; и 4) для последующего выполнения графа производителей, начинают выполнение от поднабора исходных производителей, который состоит из тех исходных производителей, которые подменены и/или добавлены начиная с последнего выполнения.

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

Примерные типы зависимостей

Примерные динамические зависимости производителя

Динамическая зависимость производителя - это зависимость производителя, которая может изменяться во время выполнения. Следует понимать, что критерии для разрешения зависимости производителя присутствуют в исходном коде, и таким образом производители, для которых может быть разрешена зависимость производителя, ограничены. Со ссылкой на фиг. 3A, пунктирная линия со стрелками от модуля 345 выполнения графа производителей к модулю 340 автоматического формирования графов производителей представляет поддержку выполнения одного или более производителей в текущем графе производителей, которые необходимы для того, чтобы обнаруживать и собирать весь текущий граф производителей. Другими словами, вариант осуществления изобретения, который поддерживает динамические зависимости производителя, может выполнять итерации между модулем 340 автоматического формирования графов производителей и модулем 345 выполнения графа производителей, пока весь граф производителей не обнаружен, построен, разрешен и выполнен (т.е. выполнять итерации между: 1) вызовом модуля автоматического формирования графов производителей, чтобы обнаруживать и строить эти части текущего графа производителей, которые могут быть разрешены в это время; и 2) вызовом модуля выполнения графа производителей, чтобы выполнять производителей текущего графа производителей). В этом смысле обнаружение упоминается как осуществление доступа к объявлениям зависимостей производителя и определение производителей, которые они идентифицируют; построение упоминается как создание экземпляров производителей и добавление их к графу производителей; а разрешение упоминается как определение в текущих неразрешенных динамических зависимостях производителя.

Фиг. 5A - это блок-схема, иллюстрирующая обнаружение и построение примерного графа производителей, включающего в себя неразрешенную зависимость, согласно одному варианту осуществления изобретения. Фиг. 5A показывает текущий набор интересующих производителей, состоящий из производителя 1. На основе производителя 1 и его объявления зависимостей производителя, производитель 2 и производитель 3 обнаруживаются. Другими словами, объявление зависимости для производителя 1 идентифицирует то, что производитель 1 требует в качестве вводов вывод производителя 2 и производителя 3. Фиг. 5A также показывает то, что хотя производитель 3 является независимым производителем (и таким образом, исходным производителем), производитель 2 не является. Как результат, на основе объявления зависимости производителя 2, обнаруживаются производитель 4 и производитель 5. Дополнительно, фиг. 5A показывает то, что хотя производитель 4 является независимым производителем (и таким образом, исходным производителем), производитель 5 не является таковым. Как результат, на основе объявления зависимости производителя 5, обнаруживается производитель 6 и текущая неразрешенная зависимость. Фиг. 5A также показывает то, что текущая неразрешенная зависимость может быть для производителя 7A и/или производителя 7B.

Фиг. 5B - это блок-схема, иллюстрирующая начальное выполнение графа производителей по фиг. 5A и разрешение неразрешенной зависимости согласно одному варианту осуществления изобретения. Фиг. 5B иллюстрирует граф производителей по фиг. 5A с изогнутыми линиями со стрелками, показывающими выполнение производителей и предоставление их выводов зависимым родительским производителям. Помимо этого, фиг. 5B показывает то, что неразрешенная зависимость производителя 5 разрешается как зависимость производителя 7A, и этот производитель 7A является независимым производителем.

Фиг. 5C - это блок-схема, иллюстрирующая начальное выполнение графа производителей по фиг. 5A и/или повторное выполнение графа производителей по фиг. 5B согласно одному варианту осуществления изобретения. Фиг. 5C иллюстрирует граф производителей по фиг. 5A с изогнутыми линиями со стрелками, показывающими выполнение производителей и предоставление их выводов зависимым родительским производителям. Помимо этого, фиг. 5C показывает то, что неразрешенная зависимость производителя 5 разрешается как зависимость производителя 7B, и этот производитель 7B является зависимым производителем. Как результат, на основе объявления зависимости производителя 7B, обнаруживается производитель 8. Производитель 8 является независимым производителем (и таким образом, исходным производителем). При условии, что фиг. 5C представляет начальное выполнение графа производителей фиг. 5A, все изогнутые линии со стрелками на фиг. 5C должны использоваться. Тем не менее, при условии, что фиг. 5C представляет повторное выполнение графа производителей по фиг. 5B, результаты повторного выполнения в динамической зависимости разрешаются по-другому (переключаясь от производителя 5, являющегося зависимым от производителя 7A, к производителю 7B). Дополнительно, если повторное выполнение выполняется без инкрементного выполнения, то все изогнутые линии со стрелками на фиг. 5C должны использоваться; тем не менее, если инкрементное выполнение использовалось, то только непунктирные изогнутые линии со стрелками должны использоваться (производитель 8 к производителю 7B, производитель 7B к производителю 5, производитель 5 к производителю 2 и производитель 2 к производителю 1). Также следует понимать, что динамическое изменение в зависимости, проиллюстрированное на фиг. 5C, является примерным, и таким образом любое число различных ситуаций может возникать (к примеру, динамическое изменение может никогда не возникать; производитель 5 может сначала зависеть от производителя 7B, а затем изменяться на производителя 7A; производитель 5 может сначала зависеть от производителя 7B, и динамическое изменение вообще не возникать; производитель 5, как может быть обнаружено, зависит и от производителя 7A, и от производителя 7B, как проиллюстрировано на фиг. 5D; и т.д.) Поскольку различные варианты осуществления могут разрешать динамические зависимости производителей различными способами, некоторые примеры представлены далее в данном документе.

Таким образом, автоматическое повторное выполнение графа производителей не ограничено модифицированием производителя и повторным выполнением его прямого родительского элемента; вместо этого изменение автоматически проходит через граф производителей посредством среды выполнения, затрагивая всех соответствующих производителей и зависимости, поскольку графы производителей поддерживаются (и инкрементное выполнение используется, если поддерживается). По сути, изменения приводят к любому обязательному дополнительному обнаружению, построению, разрешению и выполнению. Таким образом, повторное выполнение графа производителей автоматизировано в том смысле, что пользователь/программист не должен определять то, какие производители графа производителей затрагиваются и, возможно, вручную корректировать граф.

Статические зависимости производителя

Статическая зависимость - это то, что не может изменяться во время выполнения. Таким образом, в варианте осуществления изобретения, который поддерживает условные и подписные динамические зависимости (описанные далее), безусловная, неподписная зависимость - это статическая зависимость. Примерный граф производителей по фиг. 4A иллюстрирует граф производителей статических зависимостей.

Формы графов производителей

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

Следует понимать, что граф производителей может принимать множество различных форм (к примеру, одна цепочка производителей, дерево и т.д.). Примерный граф производителей по фиг. 5B является деревом с корневым узлом производителя 1, от которого есть два ветвления - по одному к каждому из производителя 2 и производителя 3. Если производитель 3 является концевым узлом, то производитель 2 имеет два ветвления, идущие от него, - по одному к каждому из производителя 4 и производителя 5. Производитель 5 имеет два ветвления, идущие от него, - по одному к каждому из производителя 6 и производителя 7A. Примерный граф производителей по фиг. 5B, как считается, является многоуровневым, причем уровень 1 включает в себя корневой узел производителя 1, уровень 2 включает в себя производителя 2 и производителя 3, уровень 3 включает в себя производителя 4 и производителя 5, уровень 4 включает в себя производителя 6 и производителя 7A (на фиг. 5C, уровень 4 включает в себя производителя 7B, а уровень 5 включает в себя производителя 8). При рассмотрении ветвления от производителя 1 с производителем 2, первый производитель ветвления - это производитель 2, а последние производители ветвления - это производитель 4, производитель 6 и производитель 7A на фиг. 5B.

Хотя фиг. 5B иллюстрирует граф производителей, в который текущий набор интересующих производителей включает одного производителя, варианты осуществления изобретения, которые поддерживают больше одного текущего интересующего производителя, должны обнаруживать и строить графы производителей для каждого. Следует понимать, что, если одновременно имеется несколько интересующих производителей, результирующие графы производителей могут быть независимыми или могут пересекаться. Если графы производителей пересекаются, варианты осуществления изобретения могут быть реализованы так, чтобы: 1) дублировать производителей, чтобы поддерживать отдельные графы производителей; или 2) исключать такое дублирование и поддерживать пересекающиеся графы производителей. Также следует понимать, что такие пересекающиеся графы производителей могут включать в себя граф производителей, который является поднабором другого графа производителей. Например, если производитель 5 включен с производителем 1 в текущий набор интересующих производителей, то это должен быть первый граф производителей с корневым узлом производителя 5 и второй граф производителей с корневым узлом производителя 1, где второй граф производителей включает в себя первый граф производителей. Если, например, производитель 7B включен с производителем 1 и производителем 5 в текущий набор интересующих производителей, то это должен быть третий граф производителей, отдельный от первого и второго графа производителей, с корневым узлом производителя 7B на фиг. 5B. Дополнительно, если динамическая зависимость производителя 5 изменяется от производителя 7A на производитель 7B (фиг. 5C), то изменение должно приводить к тому, что третий граф производителей становится поднабором второго оставшегося графа производителей, а второй граф производителей становится поднабором первого графа производителей. Как ранее заявлено, хотя варианты осуществления изобретения могут сохранять и обрабатывать граф(ы) производителей как совокупность графов, другие варианты осуществления изобретения сохраняют и обрабатывают граф(ы) производителей как совокупность производителей, которые связаны друг с другом, чтобы формировать граф(ы) (в противоположность совокупности графов), чтобы упрощать объединение и расщепление графов производителей. В качестве примера, а не ограничения, варианты осуществления изобретения, которые сохраняют и обрабатывают граф(ы) производителей как совокупность производителей, описываются в данном документе.

Примерный поток выполнения

Фиг. 6 - это блок-схема последовательности операций, иллюстрирующая логический поток выполнения клиента среды выполнения и его взаимосвязь со средой выполнения со средствами поддержки графоориентированного программирования на основе производителей согласно одному варианту осуществления изобретения. На фиг. 6 пунктирная разделительная линия 600 отделяет логический поток выполнения клиента 610 среды выполнения от среды выполнения со средствами 640 поддержки графоориентированного программирования на основе производителей.

Логический поток выполнения клиента 610 среды выполнения включает в себя этапы 615, 620, 625 и 630, тогда как среда выполнения со средствами 640 поддержки графоориентированного программирования на основе производителей включает в себя этапы 645, 650, 660 и, необязательно, 655. Сплошная линия со стрелками представляет прямую причинную взаимосвязь от этапа 630 с этапом 660. Напротив, пунктирные линии со стрелками иллюстрируют причинную взаимосвязь от этапов 615 и 625 в логическом потоке выполнения клиента 610 среды выполнения с этапами 645 и 650 в среде выполнения со средствами 640 поддержки графоориентированного программирования на основе производителей, соответственно; в зависимости от варианта осуществления изобретения эта причинная взаимосвязь может быть прямой или косвенной. Например, фиг. 6 иллюстрирует необязательную косвенную причинно-следственную зависимость через использование журнала 665 регистрации команд в пунктирном овале на стороне среды выполнения со средствами 640 поддержки графоориентированного программирования на основе производителей пунктирной линии 600. Журнал 665 регистрации команд собирает команды, вытекающие из этапов 615 и 625 логического потока выполнения клиента 610 среды выполнения; и журнал 655 регистрации команд используется, в ответ на этап 630, посредством этапа 660 обработки. Таким образом, журнал 665 регистрации команд предоставляет возможность отсрочки команд, чтобы собирать несколько из них вместе и обрабатывать в пакетном режиме их в целях оптимизации. Таким образом, журнал 665 регистрации команд аналогичен журналу 396 регистрации подмены по фиг. 3B и фактически должен включать в себя журнал 396 регистрации подмены в некоторых вариантах осуществления изобретения.

На этапе 615, набор из одного или более интересующих производителей определяется как текущий набор интересующих производителей, и управление переходит к этапу 620. В ответ на причинную взаимосвязь между этапом 615 и этапом 645, этап 645 показывает то, что создаются экземпляры текущего набора интересующих производителей и что делается попытка обнаруживать, строить и разрешать (если динамические зависимости поддерживаются и одна или более обнаружены на графе производителей) граф(ы) производителей для каждого, включая создание всех экземпляров и их производителей по мере необходимости на основе объявлений зависимостей производителя в клиенте 610 среды выполнения. Со ссылкой на фиг. 3A и 3B, модули 340 и 365 автоматического формирования графов производителей активируются, соответственно.

На этапе 620, определяется, есть ли какие-нибудь подмены выводов производителей. Если да, управление переходит к этапу 625; иначе, управление переходит к этапу 630.

На этапе 625, одна или более подмен выводов производителей принимаются для набора из одного или более производителей, и управление переходит к этапу 630. В ответ на причинную взаимосвязь между этапом 625 и этапом 650, этап 650 показывает то, что создаются экземпляры текущего набора подмененных производителей (если уже не созданы экземпляры на этапе 645), их выводы модифицируются, и они отслеживаются. Для подмененного производителя, возможно, уже создан экземпляр, поскольку он уже обнаружен как часть графа(ов) производителей на этапе 645. Тем не менее, подмененный производитель может еще не быть обнаружен на этапе 645 из-за неразрешенной динамической зависимости. По сути, для этого подмененного производителя создается экземпляр, и он подменяется математическим ожиданием того, что он может быть добавлен к графу(ам) производителей, когда динамические зависимости разрешены. Кроме этого, как ранее указано, журнал 396 регистрации подмены по фиг. 3B, если реализован, предусмотрен между этапом 625 и этапом 650 и является частью журнала 665 регистрации команд. Дополнительно, набор подмененных производителей отслеживается в некоторых вариантах осуществления изобретения, которые поддерживают инкрементное выполнение. Хотя в вариантах осуществления изобретения, которые поддерживают журнал 396 регистрации подмены/журнал 665 регистрации команд, отслеживание - это часть журнала регистрации, в альтернативных вариантах осуществления изобретения, отслеживание выполняется отдельно на этапе 650 с помощью другого механизма.

На этапе 630, модуль выполнения графа производителей активируется, и управление необязательно возвращается к этапу 615 и/или этапу 625. В ответ на причинную взаимосвязь между этапом 630 и этапом 660, этап 660 показывает то, что текущий граф(ы) производителей обходится, и все производители, которые требуют выполнения, выполняются на основе отслеживания. Различные методики для выполнения производителей графа производителей ранее пояснены и применимы здесь. Со ссылкой на фиг. 3A и 3B, модули 345 и 370 выполнения графа производителей активируются, соответственно. Помимо этого, в вариантах осуществления изобретения, в которых реализован журнал 665 регистрации команд, причинная взаимосвязь включает в себя применение журнала 665 регистрации команд и выполнение этапов обработки 645 и 650 перед этапом 660. Дополнительно, в вариантах осуществления изобретения, которые поддерживают возможность неразрешенных зависимостей, управление переходит от этапа 660 к этапу 655, когда необходимо.

На этапе 655, делается попытка разрешать неразрешенные зависимости и обнаруживать и строить оставшуюся часть графа(ов) производителей, включая создание всех экземпляров и их производителей. От этапа 655 управление возвращается к этапу 660.

Примерные формы объявлений зависимостей производителя

Фиг. 7A-F иллюстрируют некоторые примерные формы для объявлений зависимостей производителя согласно вариантам осуществления изобретения. Хотя фиг. 7A-F иллюстрируют варианты осуществления, которые поддерживают зависимости аргументов, полей и упорядочения, следует понимать, что другие варианты осуществления могут поддерживать только одну или две из трех форм зависимостей. В вариантах осуществления изобретения, показанных на фиг. 7A-F, объявление зависимостей производителя состоит из оператора объявления зависимостей производителя и, необязательно, явного кода объявления зависимостей производителя. Несокращенная объявленная зависимость производителя - это зависимость, в которой используется явный код объявления зависимостей производителя, тогда как сокращенная объявленная зависимость производителя - это зависимость, в которой не используется никакой явный код объявления зависимостей производителя (наоборот, среда выполнения не использует код объявления зависимостей производителя и/или реализует его "на лету" на основе информации в операторе объявления зависимостей производителя).

Различные варианты осуществления изобретения могут использовать различные синтаксисы для объявления зависимостей производителя. Например, различные варианты осуществления изобретения могут включать в себя различные синтаксисы для использования в операторах объявления зависимостей производителя, которые строго ограничивают, слабо ограничивают и/или не ограничивают тип зависимости производителя, которая может быть создана. Строго ограниченная зависимость производителя - это зависимость, для которой в операторе объявления зависимостей производителя используется синтаксис, который существенно ограничивает тип зависимости производителя, которая может быть создана; слабо ограниченная зависимость производителя - это зависимость, для которой в операторе объявления зависимостей производителя используется синтаксис, который в меньшей степени ограничивает тип зависимости производителя, которая может быть создана; и неограниченная зависимость производителя - это зависимость, для которой в операторе объявления зависимостей производителя используется синтаксис, который не ограничивает тип зависимости производителя, которая может быть создана.

В качестве примера, а не ограничения, варианты осуществления изобретения, описанные ниже, включают в себя следующее: 1) синтаксис для строго ограниченной зависимости производителя для аргументов (ArgumentDependency = строго ограниченная нисходяще объявляемая зависимость аргументов [статическая или динамическая, и если динамическая, условная и/или на основе поглощающей подписки]); 2) синтаксис для строго ограниченной зависимости производителя для полей (FieldDependency = строго ограниченная нисходяще объявляемая зависимость полей [статическая или динамическая, и если динамическая, условная и/или на основе поглощающей подписки]); 3) синтаксис для строго ограниченной зависимости производителя для зависимостей упорядочения (SequencingDependency = строго ограниченная нисходяще объявляемая зависимость упорядочения [статическая или динамическая, и если динамическая, условная и/или на основе прикрепляющей подписки]); 4) синтаксис для слабо ограниченной восходяще объявляемой зависимости производителя для зависимостей аргументов, полей или упорядочения (UpwardDependency = слабо ограниченная восходяще объявляемая зависимость полей, аргументов или упорядочения [статическая или динамическая, и если динамическая, условная]); и 5) синтаксис для слабо ограниченной зависимости производителя (WeaklyConstrainedDependency = или a) нисходяще объявляемая только зависимость упорядочения [статическая или динамическая, и если динамическая, условная и/или на основе прикрепляющей подписки]; или b) восходяще объявляемая зависимость [аргументов, полей или упорядочения] [статическая или динамическая, и если динамическая, условная]). Следует понимать, что хотя некоторые варианты осуществления изобретения поддерживают синтаксис для оператора объявления зависимостей производителя, который отличает нисходяще объявляемые зависимости аргументов, нисходяще объявляемые зависимости полей, восходяще объявляемые зависимости (которые могут возвращать восходяще объявляемые зависимости аргументов, полей или упорядочения) и слабо ограниченные зависимости (которые могут возвращать нисходяще объявляемые зависимости упорядочения, восходяще объявляемые зависимости аргументов, полей или упорядочения), альтернативные варианты осуществления изобретения могут приспосабливать другой синтаксис (к примеру, иметь синтаксис, который задает все зависимости как неограниченные зависимости с производителями определения зависимостей, которые могут возвращать любые поддерживаемые зависимости (нисходяще и восходяще объявляемые зависимости аргументов, полей и упорядочения); иметь синтаксис, который различает все поддерживаемые зависимости; иметь синтаксис, который различает нисходяще и восходяще объявляемые зависимости аргументов и полей и который отличает слабо ограниченную зависимость, которая может возвращать только восходяще и нисходяще объявляемые зависимости упорядочения; синтаксис, который различает нисходяще объявляемые зависимости аргументов и полей и который различает восходяще объявляемые зависимости, которые могут возвращать только восходяще объявляемые зависимости упорядочения; синтаксис, который различает нисходяще объявляемые зависимости аргументов, полей и упорядочения (на основе прикрепляющей подписки и восходяще объявляемые зависимости не поддерживаются); и т.д.).

Следует понимать, что синтаксис оператора объявления зависимостей производителя не обязательно приравнивается к зависимости производителя (к примеру, связи), созданной на графе производителей (к примеру, ArgumentDependency создает зависимость аргументов; но UpwardDependency может создавать зависимость аргументов, полей или упорядочения). По сути, где надлежит для понимания, пробел между спецификатором (к примеру, аргументом, полем или упорядочением) и словом "зависимость" используется для того, чтобы относиться к зависимости, создаваемой посредством среды выполнения, тогда как отсутствие пробела используется для того, чтобы относиться к синтаксису.

Фиг. 7A иллюстрирует псевдокод объявления зависимостей производителя для метода с использованием сокращенных объявленных зависимостей согласно одному варианту осуществления изобретения; тогда фиг. 7B - это блок-схема примерных производителей согласно одному варианту осуществления изобретения. Фиг. 7A показывает: 1) оператор 705 объявления зависимостей производителя, включающий в себя ArgumentDependencies 1-N, FieldDependencies 1-M, SequencingDependencies 1-L, UpwardDependencies 1-P и WeaklyConstrainedDependencies 1-Q; и 2) метод альфа 710, имеющий аргументы 1-N оператора 705 объявления зависимостей производителя. В одном варианте осуществления изобретения, аргументы оператора объявления зависимостей производителя нумеруются таким образом, чтобы предоставлять идентификатор аргумента для каждого для целей отслеживания. Фиг. 7B показывает производителя 720, имеющего дочерние зависимости со следующим: 1) производитель 725 для идентификатора аргумента 1; 2) производитель 730 для идентификатора аргумента N; 3) производители 740-745 для FieldDependencies 1-M; 4) производители 746-747 для SequencingDependencies 1-L; и 5) производители 748-749 для UpwardDependencies 1-P (отметим, что WeaklyConstrainedDependencies 1...Q не показаны, но подробнее описаны со ссылкой на фиг. 7G). Таким образом, аргументы оператора 705 объявления зависимостей производителя соответствуют аргументам метода альфа 710, и идентификаторы аргументов в операторе 705 объявления зависимостей производителя отслеживаются относительно дочерних производителей, которые они идентифицируют.

Фиг. 7C иллюстрирует псевдокод объявления зависимостей производителя для метода с использованием несокращенной объявленной зависимости и иллюстрирует блок-схему примерных производителей согласно одному варианту осуществления изобретения. Фиг. 7C показывает оператор 705 объявления зависимостей производителя и метод альфа 710 по фиг. 7A, а также производители 720 и 725 из фиг. 7B. Помимо этого, фиг. 7C включает в себя код 715 объявления зависимостей производителя, ассоциативно связанный с ArgumentDependency 1. В ходе выполнения среда выполнения осуществляет доступ и выполняет код 715 объявления зависимостей производителя в ответ на ArgumentDependency 1 из оператора 705 объявления зависимостей производителя. Выполнение кода 715 объявления зависимостей производителя возвращает производителя 725 как зависимость производителя для ArgumentDependency 1. Таким образом, фиг. 7C иллюстрирует варианты осуществления изобретения, в которых код 715 объявления зависимостей производителя может быть частью метода (кроме метода альфа 710), но не является частью производителя.

Фиг. 7D иллюстрирует псевдокод объявления зависимостей производителя для метода с использованием несокращенной объявленной зависимости согласно одному варианту осуществления изобретения; тогда как фиг. 7E - это блок-схема примерных производителей согласно одному варианту осуществления изобретения. Фиг. 7D показывает оператор 705 объявления зависимостей производителя и метод альфа 710 по фиг. 7A, тогда как фиг. 7E показывает производители 720 и 725 из фиг. 7B. Помимо этого, фиг. 7D включает в себя: 1) оператор 750 объявления зависимостей производителя; и 2) метод бета 755, включающий в себя код 760 объявления зависимостей производителя. Фиг. 7D также показывает то, что зависимость аргументов 1 из оператора 705 объявления зависимостей производителя идентифицирует производитель (показанный на фиг. 7E как производитель 765) на основе метода бета 755, который должен возвращать зависимость для зависимости аргументов 1. В ходе выполнения, среда выполнения, в ответ на зависимость аргументов 1 из оператора 705 объявления зависимостей производителя, выполняет производитель 765, чтобы возвращать идентификацию того, что зависимость производителя для зависимости аргументов 1 является производителем 725. По сути, производитель 765 упоминается как производитель определения зависимостей (его выводом является зависимость производителя - и таким образом, возвращается с использованием класса/экземпляра, который отслеживается для специальной обработки (обработки графа(ов) производителей посредством среды выполнения со средствами поддержки графоориентированного программирования на основе производителей), тогда как производитель 725 упоминается как стандартный производитель (его вывод, если таковой имеется, не обрабатывается непосредственно средой выполнения, чтобы манипулировать графом производителей; но его вывод, если таковой имеется, может быть использован посредством родительского производителя (будь это производитель определения зависимостей или другой стандартный производитель) и/или предоставлен как вывод графа производителей (если стандартный производитель - это интересующий производитель, и таким образом корневой узел).

Таким образом, фиг. 7D-E иллюстрируют варианты осуществления изобретения, в которых код 715 объявления зависимостей производителя - это часть другого производителя, упоминаемого как производитель определения зависимостей. Хотя на фиг. 7D-E объектно-ориентированный исходный код включает в себя явный код объявления зависимостей производителя в методах, из которых создаются экземпляры производителей определения зависимостей во время выполнения посредством среды выполнения для несокращенных объявленных зависимостей, альтернативные варианты осуществления изобретения дополнительно или вместо этого реализуют среду выполнения так, чтобы включать в себя универсальный код объявления зависимостей производителя, который она активирует как одного или более универсальных производителей определения зависимостей "на лету" для сокращенных объявленных зависимостей. Кроме этого, хотя фиг. 7C-E проиллюстрированы в отношении ArgumentDependencies, проиллюстрированные методики применимы к другим типам нисходяще объявляемых зависимостей. Дополнительно, фиг. 7F-G иллюстрируют использование производителя определения зависимостей для UpwardDependency и WeaklyConstrainedDependency.

Фиг. 7F - это блок-схема примерной зависимости через использование UpwardDependency с производителем определения зависимостей согласно одному варианту осуществления изобретения. Фиг. 7F показывает производитель 720, имеющий зависимость упорядочения производителя от производителя 772 определения зависимостей. Производитель определения зависимостей может возвращать неподписную восходяще объявляемую зависимость аргументов, полей или упорядочения родительского производителя 748 от производителя 720. Дополнительно, такой производитель определения зависимостей может реализовать динамическую зависимость (к примеру, условную зависимость, которая выбирает между вышеупомянутым в зависимости от значений данных, в том числе между различными идентификаторами аргументов, как описано далее в данном документе). Хотя некоторые варианты осуществления изобретения поддерживают все эти возможности, альтернативные варианты осуществления изобретения поддерживают только поднабор (к примеру, только неподписные восходяще объявляемые зависимости упорядочения).

Фиг. 7G - это блок-схема возможных примерных зависимостей через использование WeaklyConstrainedDependency с производителем определения зависимостей согласно одному варианту осуществления изобретения. Фиг. 7G показывает производитель 720, имеющий зависимость упорядочения производителя от производителя 775 определения зависимостей. В некоторых вариантах осуществления изобретения, производитель определения зависимостей может возвращать любое из следующего: 1) неподписная нисходяще объявляемая зависимость упорядочения от дочернего производителя 780; 2) неподписная восходяще объявляемая зависимость аргументов, полей или упорядочения родительского производителя 785 от производителя 720; и 3) прикрепляющая подписка (описанная далее в данном документе). Дополнительно, такой производитель определения зависимостей может реализовать динамическую зависимость (к примеру, условную зависимость, которая выбирает между вышеупомянутым в зависимости от значений данных, в том числе между различными идентификаторами аргументов, как описано далее в данном документе). Хотя некоторые варианты осуществления изобретения поддерживают все эти возможности, альтернативные варианты осуществления изобретения поддерживают только поднабор (к примеру, только неподписные восходяще объявляемые зависимости упорядочения).

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

Различные варианты осуществления могут поддерживать один или более способов объявления зависимостей производителя относительно производителей свойств. В частности, в некоторых вариантах осуществления изобретения, производители, которые считывают поле, должны зависеть от производителя получения свойств, тогда как производитель получения свойства должен зависеть от всех производителей, которые задают поле, за которое этот метод получения свойства отвечает. Одна методика обработки этой ситуации, которая может использоваться в вариантах осуществления изобретения, которые поддерживают зависимости упорядочения производителя, должна предоставлять, для метода получения свойства, оператор объявления зависимостей производителя, который создает зависимости упорядочения производителя в каждом методе, который задает поле, за которое этот метод получения свойства отвечает (к примеру, относительно фиг. 7G, где производитель 780 является производителем, который задает поле, а производитель 720 является производителем получения свойств, отвечающим за то поле, производитель 775 определения зависимостей должен быть написан так, чтобы возвращать нисходяще объявляемую зависимость упорядочения производителя 720 от производителя 780). Вторая методика обработки этой ситуации, которая может использоваться в вариантах осуществления изобретения, которые поддерживают как зависимости упорядочения производителя, так и восходяще объявляемые зависимости производителя, состоит в том, чтобы включать, в оператор/код объявления зависимости производителя для любого метода, который задает поле, восходяще объявляемую зависимость упорядочения производителя (к примеру, с помощью UpwardDependency или WeaklyConstrainedDependency) для метода получения, отвечающего за это поле (к примеру, относительно фиг. 7G, если производитель 720 является производителем, который задает поле, а производитель 785 является производителем получения свойств, отвечающим за это поле, производитель 775 определения зависимостей должен быть написан так, чтобы возвращать восходяще объявляемую зависимость упорядочения родительского производителя 785 от производителя 720). Эта вторая методика дает возможность программисту метода, который задает поле, быть ответственным за предоставление зависимости производителя соответствующему методу получения, в противоположность от необходимости того, чтобы программист переходил к методу получения и модифицировал его оператор/код объявления зависимости производителя.

При использовании зависимостей упорядочения, когда данный производитель базируется на данной переменной, эта переменная не должна модифицироваться посредством более одного из производителей-потомков этого производителя при данном выполнении графа(ов) производителей. (Следует отметить, что через условные зависимости (описанные далее в данном документе) различные производители-потомки могут модифицировать эту переменную в ходе различных выполнений текущего графа(ов) производителей). Например, производитель получения свойств должен зависеть только от одного другого производителя, который задает поле, за которое производитель получения свойств отвечает при данном выполнении текущего графа(ов) производителей.

Следует понимать, что различные варианты осуществления изобретения могут реализовать один или более из вариантов осуществления изобретения, показанных на фиг. 7A-F. Например, один вариант осуществления изобретения поддерживает сокращенные и несокращенные объявленные зависимости, обе из которых используют производители определения зависимостей; в частности, в этом варианте осуществления изобретения: 1) объектно-ориентированный исходный код включает в себя явный код объявления зависимостей производителя в методах, из которых создаются экземпляры производителей определения зависимостей во время выполнения посредством среды выполнения для несокращенных объявленных зависимостей; 2) среда выполнения включает в себя универсальный код объявления зависимостей производителя, который она активирует как один или более универсальных производителей определения зависимостей, "на лету" для сокращенно объявленных, условных зависимостей (описанных далее в данном документе); и 3) среда выполнения включает в себя поддержку, чтобы непосредственно связывать сокращенно объявленные, безусловные зависимости производителя (описаны далее в данном документе).

В качестве еще одного примера, один вариант осуществления изобретения поддерживает несокращенные и сокращенные объявляемые зависимости производителя с использованием производителей определения зависимостей; в частности, в этом варианте осуществления изобретения: 1) объектно-ориентированный исходный код включает в себя явный код объявления зависимостей производителя в методах, из которых создаются экземпляры производителей определения зависимостей во время выполнения посредством среды выполнения для несокращенных объявленных зависимостей; и 2) среда выполнения включает в себя универсальный код определения зависимости, который она активирует как один или более универсальных производителей определения зависимостей "на лету" для сокращенных объявленных зависимостей (независимо от типа). Этот второй вариант осуществления предоставляет возможность согласованной обработки зависимостей производителя и, таким образом, упрощает выполнение.

Помимо этого, хотя в одном варианте осуществления изобретения оператор объявления зависимостей производителя для метода находится непосредственно выше этого метода в объектно-ориентированном исходном коде, в альтернативных вариантах осуществления изобретения он находится в другом месте (к примеру, операторы объявления зависимостей производителя для всех методов класса группируются в рамках класса, операторы объявления зависимостей производителя для всех методов во всех классах группируются как отдельная таблица данных и т.д.). Кроме этого, хотя в одном варианте осуществления изобретения код объявления зависимостей производителя является отдельным от операторов объявления зависимостей производителя, в альтернативных вариантах осуществления изобретения они комбинируются (к примеру, код объявления зависимостей производителя находится в круглых скобках оператора объявления зависимостей производителя, код объявления зависимостей производителя помещается непосредственно ниже оператора объявления зависимостей производителя и обрабатывается посредством среды выполнения как единый блок и т.д.).

Фиг. 7H-I иллюстрируют различие между различными подграфами, которые могут существовать на графе производителей вследствие производителей определения зависимостей. Фиг. 7H иллюстрирует примерные графы производителей для стандартных производителей согласно одному варианту осуществления изобретения. В частности, фиг. 7H показывает граф производителей с корневым узлом S1, граф производителей с корневым узлом S5 и граф производителей с корневым узлом S11. Стандартный производитель S1 имеет в качестве дочерних стандартные производители S2, S3, и S4; стандартные производители S2 и S3 имеют в качестве дочерних стандартные производители S7 и S8; стандартный производитель S5 имеет в качестве дочерних стандартные производители S4 и S6; и стандартный производитель S11 имеет в качестве дочерних стандартные производители S6 и S10. Примерные графы производителей по фиг. 7H могут быть обнаружены, построены и повернуты с помощью любого числа зависимостей производителя и производителей определения зависимостей. Фиг. 7I иллюстрирует один пример зависимостей производителя и производителей определения зависимостей для обнаружения, разрешения и построения графа производителей по фиг. 7H. В частности, фиг. 7I показывает графы по фиг. 7H, которые являются подграфами большего набора графов производителей. Другими словами, графы производителей по фиг. 7I включают в себя графы по фиг. 7H (упоминаемые как "целевые подграфы" и проиллюстрированные с помощью сплошных линий со стрелками и сплошных овалов) и графы, которые помогают в обнаружении, разрешении и построении целевых подграфов (упоминаемые как решающие подграфы и проиллюстрированные с помощью пунктирных линий со стрелками и пунктирных овалов). Решающие подграфы на фиг. 7H включают в себя производителей определения зависимостей (DDP) 1-11 и стандартных производителей S9-10. На фиг. 7H, S1 показывается как являющийся зависимым от DDP 1-3, которые, соответственно, возвращают нисходяще объявляемые зависимости производителя S1 от S2, S3 и S4; S4 показывается как являющийся зависимым от DDP4, который возвращает восходяще объявляемую зависимость производителя S5 от S4; S5 показывается как являющийся зависимым от DDP5, который возвращает нисходяще объявляемую зависимость производителя S5 от S6; S3 показывается как являющийся зависимым от DDP6, который, в свою очередь, зависит от DDP8, который возвращает нисходяще объявляемую зависимость производителя DDP6 от S9 и S10, которая инструктирует DDP6 возвращать нисходяще объявляемую зависимость S3 от S7; S3 показывается как являющийся зависимым от DDP7, который возвращает нисходяще объявляемую зависимость производителя S3 от S8; S8 показывается как являющийся зависимым от DDP9, который возвращает прикрепляющую подписку, для которой S6 является триггерным производителем, а S11 является созданным родительским элементом (таким образом, зависимость производителя S11 от S6); S2 показывается как являющийся зависимым от DDP10, который возвращает совокупность нисходяще объявляемой зависимости производителя S2 от S7 и S8; и S11 показывается как являющийся зависимым от DDP11, который возвращает нисходяще объявляемую зависимость производителя S11 от S10. Следует понимать, что стандартный производитель может быть частью как целевого подграфа, так и решающего подграфа (к примеру, см. S10). Стоит отметить, что целевые подграфы направляются по данным в том смысле, что данные протекают от одного стандартного производителя к другому стандартному производителю вверх по графу.

Примерная инфраструктура программирования и выполнения

Фиг. 8A - это блок-схема, иллюстрирующая первую примерную инфраструктуру, в рамках которой приложения предоставляются конечным пользователям, согласно одному варианту осуществления изобретения. Инфраструктура, показанная на фиг. 8A, включает в себя три основные секции. Первая секция включает в себя создание среды выполнения со средствами 810 поддержки графоориентированного программирования на основе производителей. Эта первая секция выполняется программистами с обширными знаниями в области программирования. При работе в этой секции программисты упоминаются как программисты среды выполнения. При создании среды выполнения со средствами поддержки графоориентированного программирования на основе производителей, программисты среды выполнения включают поддержку графов производителей, а также поддержку выполнения различных типов команд, используемых в коде преобразования, коде создания экземпляра и коде подготовки данных.

Вторая секция включает в себя создание объектно-ориентированного исходного кода 820 приложения, который должен выполняться посредством среды выполнения. Объектно-ориентированный исходный код 820 приложения включает в себя две основные секции: 1) определения классов, которые включают в себя бизнес-логику, выраженную в методах с объявлениями 822 зависимостей производителя (это необязательно может включать в себя другую функциональность, такую как графический пользовательский интерфейс, причем графический пользовательский интерфейс пишется с использованием производителей и объявлений зависимостей производителя); и 2) определения 824 классов, которые включают в себя клиентский код, выраженный в методах, включающий в себя код 824A создания экземпляра (интересующие классы, экземпляры и производитель(и), чтобы инструктировать формирование графа(ов) производителей), код 824B подготовки данных (к примеру, команды задания, такие как команды задания, которые запускают подмену выводов производителя), команды 824C глобального выполнения, чтобы инструктировать выполнение графа(ов) производителей (к примеру, команды выполнения и получения), и любой требуемый графический пользовательский интерфейс 824D (не включенный в 822). Объявления зависимостей производителя используются для того, чтобы задавать связи между производителями в ходе определения классов, которые включают в себя бизнес-логику, а не после того как экземпляры этих классов созданы. Объектно-ориентированный исходный код 820 является жестко кодированными классами, экземплярами и методами, которые компилируются и выполняются.

Хотя в одном варианте осуществления изобретения, реализована команда глобального выполнения, выполнение которой вызывает попытку выполнения всего графа(ов) производителей, имеющихся в настоящий момент в структуре 380 графа(ов) производителей, альтернативные варианты осуществления изобретения альтернативно или также реализуют конкретную для графа команду выполнения, которая требует идентификации данного графа из текущего графа(ов) производителей, который должен быть выполнен. Дополнительно, команда глобального выполнения может быть явной (к примеру, задание, задание, задание, выполнение, получение, получение) или неявной в зависимости от реализации среды выполнения. Например, неявная команда глобального выполнения может быть: 1) запущенной посредством первой команды получения для интересующего производителя (к примеру, задание, задание, задание, получение (неявное выполнение), получение); 2) запускаемой посредством каждого манипулирования данными (задание (неявное выполнение), задание (неявное выполнение), задание (неявное выполнение), получение, получение); и т.д.

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

Третья секция включает в себя использование прикладных программ, выполняемых посредством среды выполнения. Третья секция выполняется конечными пользователями, которым не требуются какие-либо знания в области программирования. Прикладная программа может распространяться множеством способов (к примеру, как исходный код, преобразование исходного кода, такое как байтовый код; как двоичный код и т.д.). Помимо этого, прикладная программа может распространяться для автономного использования 830 (в этом случае вся прикладная программа (и среда выполнения, если еще не присутствует) предоставляется в компьютерной системе) и/или для клиент-серверного использования. В одном варианте осуществления изобретения, клиент-серверное распространение включает в себя распространение определений классов, которые включают в себя бизнес-логику, выраженную в методах с объявлениями 822 зависимостей производителя (и среду выполнения, если еще не присутствует) для использования 832 посредством сервера, и определений классов, которые включают в себя клиентский код, выраженный в методах 824 (и среду выполнения, если еще не присутствует) для использования 834 посредством клиента, где использование 834 посредством клиента на компьютерной системе инструктирует обмен данными с использованием 832 посредством сервера в серверной системе.

Фиг. 8A также показывает необязательный конфигурируемый интерактивный модуль 840 графического пользовательского интерфейса формата вывода производителя, предоставляемый для автономного использования 830 и использования 834 посредством клиента. Объектно-ориентированный исходный код 820 должен выполняться посредством среды выполнения, чтобы формировать граф(ы) производителей, и конфигурируемый интерактивный модуль 840 графического пользовательского интерфейса формата вывода производителя предоставляет возможность графического отображения выводов и взаимодействия с графами производителей. В частности, конфигурируемый интерактивный модуль 840 графического пользовательского интерфейса формата вывода производителя включает в себя: 1) модуль 844 графического пользовательского интерфейса конфигурирования и согласования, чтобы предоставлять возможность конфигурирования формата и отображения выбранных выводов производителя (к примеру, областей экрана, которые должны использоваться, как данные должны быть отображены, и т.д.); и 2) модуль 846 графического пользовательского интерфейса визуализации и интерактивного просмотра, чтобы визуализировать конфигурируемый формат и предоставлять возможность подмены выводов производителя (что приводит к обновлению графов производителей через команду глобального выполнения). Следует понимать, что конфигурируемый интерактивный модуль 840 графического пользовательского интерфейса формата вывода производителя может быть или может не быть создан посредством того же объекта, что пишет среду 810 выполнения.

Фиг. 8B - это блок-схема, иллюстрирующая вторую примерную инфраструктуру, в рамках которой приложения предоставляются конечным пользователям, согласно одному варианту осуществления изобретения. Фиг. 8B идентична фиг. 8A со следующими исключениями: 1) автономное использование 830 отсутствует; 2) объектно-ориентированный исходный код 820 предоставляется для использования 832 посредством сервера, тогда как клиентский код 824 не предоставляется для использования 834 посредством клиента; 3) конфигурируемый интерактивный модуль 840 графического пользовательского интерфейса формата вывода производителя предоставляется для использования 832 посредством сервера и не предоставляется для использования 834 посредством клиента; и 4) универсальный конфигурируемый интерактивный клиентский интерфейс 885 формата вывода производителя предоставляется для использования 834 посредством клиента. Конфигурируемый интерактивный клиентский интерфейс 885 формата вывода производителя используется для того, чтобы взаимодействовать с конфигурируемым интерактивным модулем 840 графического пользовательского интерфейса формата вывода производителя.

Независимо от используемой инфраструктуры, в одном варианте осуществления изобретения, инфраструктура графоориентированного программирования на основе производителей предлагает возможность взаимодействовать с программами, не написанными с объявлениями зависимостей производителя. Эта возможность взаимодействовать с программами, не написанными с объявлениями зависимостей производителя, включает в себя: 1) вызывающую часть (такую как графический пользовательский интерфейс, не написанный согласно графоориентированному программированию на основе производителей); и 2) вызываемую часть (такую как внешний источник данных, не написанный согласно графоориентированному программированию на основе производителей). Вызывающая часть может, через клиентский код, выдавать команды графоориентированного программирования на основе производителей. Вызываемая часть реализуется как часть производителей, которые заключают в оболочку вызываемую часть (упоминаемые как "обертывающие производители"). Выполнение вызываемой части (к примеру, считывание данных из источника данных или подписка на изменения данных во внешнем источнике данных) может, в свою очередь, запускать модификации экземпляра. Эти изменения могут возникать посредством вызова методов задания свойств в коде обертывающих производителей. Производители получения свойств (получатели) инструктируются иметь зависимости от этих обертывающих производителей, чтобы удостоверяться в том, что модификации экземпляра, запущенные посредством изменений, возникающих во внешнем источнике данных, надлежащим образом распространяются через граф производителей. Как ранее описано, различные варианты осуществления могут поддерживать один или более способов объявления зависимостей производителя относительно производителей свойств. Например, в некоторых вариантах осуществления изобретения, которые поддерживают зависимости упорядочения производителя, SequencingDependencies может использоваться для объявления неподписных нисходяще объявляемых зависимостей упорядочения производителя для обертывающих производителей. В качестве еще одного другого примера, в некоторых вариантах осуществления изобретения, которые поддерживают зависимости упорядочения производителя и неподписные восходяще объявляемые зависимости производителя, UpwardDependencies и/или WeaklyConstrainedDependencies могут быть помещены в объявление зависимостей производителя обертывающих производителей, чтобы создавать неподписные восходяще объявляемые зависимости упорядочения производителя для производителей свойств.

Фиг. 8C-F иллюстрируют примерные снимки экрана и использование конфигурируемого интерактивного модуля 840 графического пользовательского интерфейса формата вывода производителя согласно одному варианту осуществления изобретения. Хотя варианты осуществления изобретения описаны в отношении конфигурируемого интерактивного модуля 840 графического пользовательского интерфейса формата вывода производителя, предоставляющего конфигурирование, отображение и взаимодействие с выбранными выводами текущего графа(ов) производителей в форме электронной таблицы, альтернативные варианты осуществления изобретения могут быть реализованы так, чтобы дополнительно или альтернативно предоставлять поддержку другой формы. Дополнительно, хотя примерные способы выполнения конфигурирования, отображения и взаимодействия в форме электронной таблицы описываются согласно некоторым вариантам осуществления, другие варианты осуществления изобретения могут выполнять эти операции другим образом, с другим интерфейсом и/или с другим форматом отображения. Дополнительно, электронная таблица может поддерживать любую из известных функциональностей, ассоциативно связанных с электронными таблицами (к примеру, выбор цветов, выбор шрифтов, столбчатые/круговые/линейные диаграммы, сводные таблицы, форматы сохранения, форматы загрузки и т.д.).

Фиг. 8C-D иллюстрируют примерные снимки экрана и использование свободного выбора ячеек согласно одному варианту осуществления изобретения, тогда как фиг. 8E-F, иллюстрируют примерные снимки экрана и использование создания таблицы согласно одному варианту осуществления изобретения. Каждая из фиг. 8C-F включает в себя строку 850 в верхней части экрана, список классов (с методами получения свойств) 852 производителей в текущем графе производителей и их выводами в нижней левой части экрана и модуль 854 просмотра, конфигурирования и согласования, заполняющий оставшуюся часть экрана в формате электронной таблицы. Помимо этого, фиг. 8C-F также показывают следующий примерный список классов с их методами получения свойств в списке 852: 1) класс PERSON; 2) методы получения свойств класса PERSON, включая FIRSTNAME (к примеру, строка), LASTNAME (к примеру, строка), GENDER (к примеру, строка), HOMEADDRESS (экземпляр класса ADDRESS), PROFESSIONALADDRESS (экземпляр класса ADDRESS), DATEOFBIRTH (к примеру, дата) и AGE (к примеру, целочисленный); 3) класс ADDRESS; и 4) методы получения свойств класса ADDRESS, включая CITY (к примеру, строка), STATE (к примеру, строка), ZIPCODE (к примеру, строка). По сути, текущий граф производителей включает в себя производителей классов PERSON и ADDRESS, а также производителей, выводы которых имеют классы PERSON и ADDRESS. Также следует отметить, что метод AGE получения свойства вычисляет возраст на основе вывода метода DATEOFBIRTH получения свойства; также производитель, экземпляр которого создается из метода AGE получения свойства, должен зависеть от производителя, экземпляр которого создается из метода DATEOFBIRTH получения свойства.

Фиг. 8C-D показывают следующий свободный текст, вводимый в последовательные ячейки первого столбца модуля просмотра: CUSTOMER, FIRST NAME, LAST NAME, DATE OF BIRTH и AGE; тогда как фиг. 8E-F показывают следующее: 1) свободный текст, вводимый в первую строку модуля просмотра - CUSTOMER LIST; и 2) свободный текст, вводимый в последовательные ячейки второй строки модуля просмотра FIRST NAME, LAST NAME, DATE OF BIRTH и AGE.

Фиг. 8C иллюстрирует примерный снимок экрана и использование свободного выбора ячеек с помощью конфигурируемого интерактивного модуля 840 графического пользовательского интерфейса формата вывода производителя согласно одному варианту осуществления изобретения. Фиг. 8C показывает набор отображений 856 класса PERSON и выбранных методов получения свойств класса PERSON в различные ячейки модуля просмотра. В частности, класс PERSON отображается в ячейку справа от свободного текста CUSTOMER. В качестве части этого действия, некоторые варианты осуществления изобретения запрашивают пользователя выбирать из одного из ряда поддерживаемых фильтров (показываемых как выбор 858 фильтра) (к примеру, раскрывающийся список, стрелки прокручивания формы и т.д.). Эти фильтры обеспечивают выбор одного или более ключей экземпляров производителей выбранного класса или одного или более ключей экземпляров производителей, выходной класс которых является выбранным классом. Хотя некоторые варианты осуществления изобретения поддерживают определенное число фильтров, другие варианты осуществления изобретения по умолчанию поддерживают один (и дают возможность пользователю определять, следует ли выбирать другой) или поддерживают только один фильтр и не требуют выполнять выбор 858 фильтра. Отображения 856 также показывают, что методы FIRSTNAME, LASTNAME, DATEOFBIRTH и AGE получения свойств класса PERSON, соответственно, отображаются в ячейки, смежные с ячейками с соответствующим свободным текстом. Такое отображение может быть выполнено с помощью любого числа известных методик, включая перетаскивание, ввод с клавиатуры в поле GUI и т.д.

Фиг. 8D иллюстрирует другой примерный снимок экрана и использование свободного выбора ячеек с помощью конфигурируемого интерактивного модуля 840 графического пользовательского интерфейса формата вывода производителя согласно одному варианту осуществления изобретения. Фиг. 8D показывает ячейку, к которой отображен класс PERSON, чтобы обеспечивать возможность выбора 854 экземпляра. В частности, на основе фильтра, используемого для этой ячейки, пользователю предоставляется возможность выбирать экземпляр класса PERSON из списка, включающего в себя ключ(и) экземпляров производителей класса PERSON, и ключи экземпляров производителей, формирующих класс PERSON. Выбор экземпляра класса PERSON (или наличие одного экземпляра) приводит к автоматической совокупности ячеек, в которые методы получения свойств класса PERSON отображены, с выводами соответствующих методов получения свойств этого экземпляра. Это заполнение таблицы на основе экземпляров класса PERSON, помечается 858. В примере по фиг. 8D, ячейки, в которые методы FIRSTNAME, LASTNAME, DATEOFBIRTH и AGE получения свойств класса PERSON отображены, соответственно, заполнены текстом JOHN, SMITH, 7/20/1990 и 16.

Фиг. 8D также показывает то, что ячейки модуля просмотра, в которые отображены методы получения свойства, могут быть подменены. В качестве примера, фиг. 8D показывает то, что если ячейка, в которую отображается метод DATEOFBIRTH получения свойства, подменяется, то это вызывает подмену вывода производителя, вывод которого в настоящий момент заполняет эту ячейку, вызов команды глобального выполнения (который должен приводить к повторному выполнению производителя, вывод которого в настоящий момент заполняет ячейку, в которую отображен метод AGE получения свойства), и любое требуемое обновление отображения.

Фиг. 8E иллюстрирует примерный снимок экрана и использование создания таблицы с помощью конфигурируемого интерактивного модуля 840 графического пользовательского интерфейса формата вывода производителя согласно одному варианту осуществления изобретения. Фиг. 8E показывает то, что операция выбора 864 зоны и ориентации выполняется для того, чтобы идентифицировать вертикальную таблицу из трех строк непосредственно под ячейками со свободным текстом FIRST NAME, LAST NAME, DATE OF BIRTH и AGE (проиллюстрированную с помощью толстой пунктирной линии вокруг этих ячеек). Различные варианты осуществления изобретения могут поддерживать пользователя, выполняющего эту операцию любым числом способов (включая: 1) выбор области с помощью устройства ввода, такого как мышь; и 2) выбор между вертикальной, горизонтальной или сводной таблицей с помощью такого интерфейса, как всплывающее меню - при условии, что несколько ориентаций поддерживается). Фиг. 8E также показывает набор отображений 866 выбранных методов получения свойств класса PERSON в различные ячейки модуля просмотра. В частности, отображения 866 показывают, что методы получения свойств FIRSTNAME, LASTNAME, DATEOFBIRTH и AGE класса PERSON, соответственно, отображаются в ячейки непосредственно под ячейками с соответствующим свободным текстом.

Фиг. 8F иллюстрирует другой примерный снимок экрана и использование создания таблицы с помощью конфигурируемого интерактивного модуля 840 графического пользовательского интерфейса формата вывода производителя согласно одному варианту осуществления изобретения. Отображения 866 приводят к автоматическому заполнению столбцов таблицы, в которую методы получения свойств класса PERSON отображены, с выводами соответствующих методов получения свойств экземпляров этого класса. Это заполнение таблицы на основе экземпляров класса PERSON помечается 868. В примере по фиг. 8D, столбцы, в которые методы получения свойств FIRSTNAME, LASTNAME, DATEOFBIRTH и AGE класса PERSON отображены, заполняются следующими строками данных: 1) STEVE, COLLINS, 7/20/1990 и 16; 2) JENNIFER, ADAMS, 7/20/1990 и 16; и 3) JOHN, SMITH, 7/20/1985 и 21.

Как и фиг. 8D, фиг. 8F показывает то, что ячейки модуля просмотра, в которые отображены методы получения свойств, могут быть подменены. В качестве примера, фиг. 8F показывает то, что если ячейка второй строки столбца, в которую отображается метод DATEOFBIRTH получения свойства, подменяется, то это вызывает подмену вывода производителя, вывод которого в настоящий момент заполняет эту ячейку, вызов команды глобального выполнения (который должен приводить к повторному выполнению производителя, вывод которого в настоящий момент заполняет ячейку, в которую отображен метод AGE получения свойства), и любое требуемое обновление отображения.

Фиг. 8C-F иллюстрируют примерные экраны, формируемые посредством модуля 842 графического пользовательского интерфейса конфигурирования и согласования. Экраны, формируемые посредством модуля 846 графического пользовательского интерфейса визуализации и интерактивного просмотра, являются одинаковыми, за исключением того, что список классов (с методами получения свойства) 852, модуль 854 просмотра, конфигурирования и согласования заменяются посредством модуля визуализации и интерактивного просмотра (не показан), который содержит такое же изображение, как отображаемый модуль 854 просмотра, конфигурирования и согласования (при этом отличие, которым является признак отображения, более недоступно).

Примерные схемы распространения среды выполнения

Фиг. 9A-C иллюстрируют различные схемы распространения среды выполнения со средствами поддержки графоориентированного программирования на основе производителей. Следует понимать, что эти схемы распространения являются примерными, и таким образом, другие схемы находятся в рамках объема изобретения.

Фиг. 9A - это блок-схема, иллюстрирующая первую схему распространения среды выполнения со средствами поддержки графоориентированного программирования на основе производителей согласно одному варианту осуществления изобретения. На фиг. 9A, объектно-ориентированный исходный код 905 (который должен включать в себя объявления зависимостей производителя) показывается поверх среды выполнения со средствами поддержки графоориентированного программирования на основе производителей 910, которая размещается поверх среды выполнения с загрузкой классов, динамическим созданием экземпляров классов, динамическим одиночным вызовом методов и анализом классов/методов 915, которая размещается поверх операционной системы 920. На фиг. 9A, среда 910 выполнения работает со средой 915 выполнения. Хотя любое число механизмов может использоваться для того, чтобы давать возможность среде 910 выполнения работать со средой 915 выполнения, средства работы с метаданными описываются в качестве примера. Средство работы с метаданными предоставляет добавление дополнительной информации в исходный код, причем эта информация используется посредством инструментальных средств разработки. Например, средство работы с метаданными для технических требований Java задает API для пометки полей, методов и классов как имеющих конкретные атрибуты, которые указывают то, что они должны обрабатываться специальными способами посредством инструментальных средств разработки, инструментальных средств развертывания или библиотеки среды выполнения (Java Specification Request 175). В этом примере, программист, программирующий объектно-ориентированный исходный код 905, должен добавлять примечания к методам в форме объявлений зависимостей производителя. Поскольку эти примечания передаются для обработки от среды 915 выполнения среде 910 выполнения, среда 910 выполнения диктует синтаксис объявлений зависимостей производителя. На фиг. 9A, среды 910 и 915 выполнения могут разрабатываться и/или распространяться различными организациями.

Фиг. 9B - это блок-схема, иллюстрирующая вторую схему распространения среды выполнения со средствами поддержки графоориентированного программирования на основе производителей согласно одному варианту осуществления изобретения. На фиг. 9B, объектно-ориентированный исходный код 925 (который должен включать в себя объявления зависимостей производителя) показывается поверх среды выполнения (с загрузкой классов, динамическим созданием экземпляров классов, динамическим одиночным вызовом методов и анализом классов/методов, а также со средствами поддержки графоориентированного программирования на основе производителей) 930, которая размещается поверх операционной системы 935. По сравнению с фиг. 9A, среды 910 и 915 выполнения комбинированы в одну среду 930 выполнения. Как результат этой комбинации, среда 930 выполнения диктует синтаксис объявлений зависимостей производителя. Таким образом, программист, программирующий объектно-ориентированный исходный код 925, должен добавлять объявления зависимостей производителя в требуемом синтаксисе.

Фиг. 9C - это блок-схема, иллюстрирующая третью схему распространения среды выполнения со средствами поддержки графоориентированного программирования на основе производителей согласно одному варианту осуществления изобретения. На фиг. 9C, объектно-ориентированный исходный код 940 (который должен включать в себя объявления зависимостей производителя) показывается поверх среды выполнения операционной системы (с загрузкой классов, динамическим созданием экземпляров классов, динамическим одиночным вызовом методов и анализом классов/методов, а также средствами поддержки графоориентированного программирования на основе производителей) 945. По сравнению с фиг. 9B, среда 920 выполнения и операционная система 935 комбинированы в один объект. Как результат этой комбинации, среда 945 выполнения операционной системы диктует синтаксис объявлений зависимостей производителя. Таким образом, программист, программирующий объектно-ориентированный исходный код 940, должен добавлять объявления зависимостей производителя в требуемом синтаксисе.

Хотя описаны варианты осуществления, в которых среда выполнения имеет загрузку классов, динамическое создание экземпляров классов, динамический одиночный вызов методов и анализ классов/методов, альтернативные варианты осуществления могут включать в себя больше или меньше признаков (к примеру, имитацию экземпляра, динамические прокси-серверы, преобразования простых типов и т.д.).

Примерные преимущества

В одном варианте осуществления изобретения, зависимости производителя объявляются для методов как способ указывать упорядочение вызова методов с использованием соответствующих экземпляров (где соответствующие экземпляры включают в себя экземпляры для использования в качестве аргументов, экземпляры, которые должны быть использованы посредством методов экземпляров, и экземпляры метаклассов, используемые посредством методов классов), не используя код упорядочения вызовов вручную. В действительности, работа по формированию некоторого или всего кода упорядочения вызовов вручную заменяется на: 1) работу, выполняемую прикладным программистом для того, чтобы писать объявления зависимостей производителя; и 2) работу, выполняемую посредством среды выполнения, чтобы обнаруживать и строить граф(ы) производителей и выполнять производителей этих графов производителей. Другими словами, логика, которая ранее содержалась в коде упорядочения вызовов вручную, является поддающейся обнаружению посредством среды выполнения в ходе выполнения на основе объявлений зависимостей производителя. Таким образом, объявления зависимостей производителя сообщают среде выполнения о том, какие методы каких экземпляров с какими аргументами выполнять и когда в целях синхронизации. Хотя объем работ для того, чтобы писать среду выполнения, является относительно большим, она должен быть написана только один раз, и далее она может использоваться для того, чтобы выполнять любые объектно-ориентированные приложения, написанные для среды выполнения; в отличие от этого, для типичного приложения объем работ для того, чтобы писать объявления зависимостей производителя, является относительно небольшим по сравнению с написанием кода упорядочения вызовов вручную.

Уменьшение ошибок программирования

Графоориентированное программирование на основе производителей типично уменьшает затраты, ассоциативно связанные с отладкой и/или настройкой производительности кода упорядочения вызовов вручную. Это истинно, по меньшей мере, по той причине, что инфраструктура прикладной программы концептуально представляет собой набор неформализованных графов методов преобразования объектов (вывод одного метода, ассоциативно связанного с объектом, является вводом в другой и т.д.), которые работают с конкретными вводами. Объявления зависимостей производителя и среда выполнения со средствами поддержки графоориентированного программирования на основе производителей формализуют эти графы как графы производителей. Таким образом, для каждой возможности изменения данных, прикладной программист не должен рассматривать ее результат и писать код упорядочения вызовов вручную, чтобы инструктировать активацию соответствующих методов преобразования соответствующих экземпляров в соответствующем порядке с соответствующими вводами. Другими словами, для каждой возможности изменения данных, прикладной программист не должен рассматривать то, какие графы затрагиваются, а также какие методы преобразования экземпляров в этих графах затрагиваются. Наоборот, модуль автоматического формирования графов производителей обнаруживает и строит графы производителей, и модуль выполнения графа производителей повторно выполняет графы производителей по мере необходимости, чтобы отражать изменения в данных. Эта автоматизация помогает прикладным программистам не допускать таких ошибок, как: 1) вызов соответствующих методов преобразования соответствующих экземпляров в неправильном порядке; 2) допущение включать команды, чтобы инструктировать активацию одного или более требуемых методов преобразования экземпляров на графе в ответ на изменение некоторых данных; 3) включение команд, чтобы инструктировать активацию ненужных методов преобразования экземпляров в ответ на изменение некоторых данных (к примеру, включение команд, чтобы активировать методы преобразования экземпляров, которые не являются частью графа, затрагиваемой изменением в данных; включение команд, чтобы активировать методы преобразования экземпляров, которые являются частью графа, затрагиваемой изменением в данных, но сами не затрагиваются; и т.д.).

Синхронизация

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

Возможность полностью пояснять любой результат

В одном варианте осуществления изобретения, модуль углубления/просмотра (не показан) включен как часть среды выполнения. Модуль углубления/просмотра предоставляет графический пользовательский интерфейс, который через взаимодействие с конечным пользователем предоставляет возможность углубления в граф производителей (прохождение графа производителей вниз от корневого узла), чтобы просматривать выводы различных производителей графа производителей. Это дает возможность конечному пользователю видеть различные выводы, которые вносят вклад в вывод интересующего производителя, включая значения данных и зависимости (возвращенные посредством производителей определения зависимостей). Дополнительно, в одном варианте осуществления изобретения, этот модуль углубления/просмотра предоставляет возможность конечному пользователю просматривать код в методах производителей, значения экземпляров производителей и/или содержимое классов производителей.

Таким образом, модуль углубления/просмотра предусматривает множество действий по постобработке, включая отладку, пояснение выводов и т.д.

Примерное практическое применение/технический эффект/промышленная применимость

Предусмотрено множество примерных практических применений различных аспектов и вариантов осуществления изобретения. Например, среда выполнения, в качестве части выполнения прикладных программ, инструктирует поиск информации с компьютерных носителей хранения (к примеру, осуществление доступа к объектно-ориентированному исходному коду, включая объявления зависимостей производителя), сохранение информации на компьютерные носители хранения (к примеру, сохранение структур данных, таких как структура графа(ов) производителей и т.д.), работу аппаратных ресурсов обработки, предоставление выводов интересующего производителя(ей) (к примеру, через графический пользовательский интерфейс, сохранение на компьютерные носители хранения, передачу и т.д.) и т.д. В одном смысле, действия по предварительной обработке включают в себя написание такой прикладной программы и/или предоставление данных (причем эти данные могут представлять любое число физических и/или практических элементов, таких как финансовые значения, географические значения, метеорологические значения, актуарные значения, статистические значения, физические показатели, значения состояния машины и т.д.), тогда как действия по постобработке включают в себя предоставление результатов (причем эти результаты могут представлять любое число физических и/или практических элементов, таких как финансовый анализ, географический анализ, метеорологический анализ, актуарный анализ, статистический анализ, индустриальные показатели, информацию машинного управления и т.д.). В качестве конкретного примера, действия по постобработке могут быть предоставлены посредством: 1) модуля 1062 просмотра графов производителей по фиг. 10 для графического отображения представления текущего графа(ов) производителей, сформированного посредством среды выполнения; и/или 2) конфигурируемого интерактивного модуля 840 графического пользовательского интерфейса формата вывода производителя (см. также, конфигурируемый интерактивный модуль 1085 графического пользовательского интерфейса формата вывода производителя по фиг. 10) для графического отображения выводов и взаимодействия с графами производителей.

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

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

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

Примерные реализации

В качестве иллюстрации, описываются примерные варианты осуществления изобретения, которые поддерживают зависимости, динамические зависимости (включая условные зависимости и подписные зависимости), производителей определения явных зависимостей для сокращенных объявленных зависимостей и для несокращенных объявленных зависимостей, производителей определения зависимостей "на лету" для сокращенных объявленных зависимостей, ключи классов, ключи экземпляров, ключи методов, команды подмены/отмены подмены производителей (которые являются типами команд задания) и команды глобального выполнения. Помимо этого, примерные варианты осуществления необязательно поддерживают модуль интерактивного просмотра графов производителей и инкрементное выполнение. Конечно, альтернативные варианты осуществления изобретения могут реализовать больше признаков, меньше признаков и/или другие признаки.

Фиг. 10 - это блок-схема примерной реализации согласно одному варианту осуществления изобретения. На фиг. 10, пунктирная разделительная линия 1000 отделяет клиента 1002 среды выполнения от среды выполнения со средствами поддержки графоориентированного программирования на основе производителей 1004.

Логический поток выполнения клиента 1002 среды выполнения включает в себя этапы 1010, 1020, 1025, 1030 и 1035, а среда выполнения со средствами поддержки графоориентированного программирования на основе производителей 1004 включает в себя, соответственно, надлежащие этапы 1095, 1098, 1040, 1045 и 1070; тогда как сплошная линия со стрелками представляет прямую причинную взаимосвязь от этапа 1035 логического потока выполнения клиента 1002 среды выполнения к этапу 1070 среды выполнения со средствами поддержки графоориентированного программирования на основе производителей 1004, пунктирные линии со стрелками иллюстрируют причинную взаимосвязь от этапов 1010, 1020, 1025 и 1030 клиента 1002 среды выполнения к этапам 1095, 1098, 1040 и 1045 среды выполнения со средствами поддержки графоориентированного программирования на основе производителей 1004. В зависимости от варианта осуществления изобретения, эти последние причинные взаимосвязи могут быть прямыми или косвенными. Например, аналогично фиг. 6, необязательная косвенная причинно-следственная зависимость через использование журнала регистрации команд (не показан) и/или журнала 1047 регистрации подмены может использоваться. Дополнительные этапы 1095 и 1098 являются пунктирными, поскольку они необязательно могут быть частью другого этапа в зависимости от варианта осуществления изобретения (к примеру, этап 1095 может быть частью этапа 1098; этап 1098 может быть частью этапа 1040; этапы 1095 и 1098 могут быть частью этапа 1040). Аналогично, этап 1045 является пунктирным, поскольку он необязательно может быть частью другого этапа в зависимости от варианта осуществления изобретения (к примеру, этап 1045 может быть частью этапа 1070).

На фиг. 10, среда 1002 выполнения включает в себя определения классов, которые включают в себя бизнес-логику 1010, имеющую данные 1012, методы 1014, объявления 1016 зависимостей производителя и необязательно ключи 1090 классов. Определения 1010 классов являются классами на языке объектно-ориентированного программирования и, таким образом, включают в себя определения для данных 1012 и методов 1014. Помимо этого, эти определения 1010 классов включают в себя объявления 1016 зависимостей производителя для метода 1014, как ранее описано. Дополнительно, в одном варианте осуществления изобретения, каждый класс имеет ключ класса 1090 для целей отслеживания.

Модуль 1095 создания новых классов среды 1004 выполнения загружает и анализирует определения 1010 классов (к примеру, в ответ на команды создания класса). Эта загрузка и анализ может выполняться с помощью любого числа известных или будущих разработанных методик, включая методики для того, чтобы выборочно загружать классы в целях оптимизации. Загрузка классов посредством модуля 1095 создания классов проиллюстрирована посредством классов 1054 среды 1004 выполнения. Как часть загрузки и анализа классов 1054, модуль 1095 создания классов также загружает и анализирует объявления 1016 зависимостей производителя, как проиллюстрировано посредством методов и объявлений 1056 зависимостей производителя в классах 1054. Модуль 1095 создания классов также поддерживает структуру 1092 отслеживания классов, которая используется для отслеживания классов с помощью ключей классов. Таким образом, структура 1092 отслеживания классов поддерживает соответствие между ключами классов и ссылками на классы 1054. Помимо этого, модуль 1095 создания классов также поддерживает структуру 1058 отслеживания методов, которая используется для отслеживания методов с использованием ключей методов. Таким образом, структура 1058 отслеживания методов поддерживает соответствие между ключами методов и ссылками на методы, а также информацией, касающейся объявлений зависимостей производителя.

Клиент 1002 среды выполнения также включает в себя команды создания экземпляра с помощью ключей 1020 экземпляров. Модуль 1098 создания экземпляров среды 1004 выполнения создает экземпляры, обозначенные посредством команд создания экземпляра с помощью ключей 1020 экземпляров (к примеру, в ответ на команды создания экземпляра). Это создание экземпляров может выполняться с помощью любого числа известных или будущих разработанных методик, включая методики для того, чтобы выборочно создавать экземпляры в целях оптимизации. Как часть этого создания экземпляров, модуль 1098 создания новых экземпляров осуществляет доступ к структуре 1092 отслеживания классов с помощью ключа класса, чтобы осуществлять доступ к соответствующему классу из классов 1054. Создание экземпляров посредством модуля 1098 создания экземпляров проиллюстрировано посредством экземпляров 1052 среды 1004 выполнения. Модуль создания экземпляров 1095 также поддерживает структуру 1065 отслеживания экземпляров, которая используется для отслеживания экземпляров с помощью ключей экземпляров. Таким образом, структура 1065 отслеживания экземпляров поддерживает соответствие между ключами экземпляров и ссылками на экземпляры 1052. Как ранее указано, модуль 1095 создания классов может быть частью модуля 1098 создания экземпляров в том, что экземпляры классов 1054 могут быть созданы в ответ на команды 1020 создания экземпляра в противоположность отдельным командам создания класса.

Клиент 1002 среды выполнения также включает в себя команды создания экземпляров производителей с помощью ключей 1025 производителей. Модуль 1040 автоматического формирования графов производителей среды 1004 выполнения создает экземпляры производителей, обозначенных посредством команд создания экземпляров производителей с помощью ключей 1025 производителей (к примеру, в ответ на команды создания производителя, обозначающие текущий набор интересующих производителей). Помимо этого, модуль 1040 автоматического формирования графов производителей также обнаруживает, строит и необязательно разрешает граф(ы) производителей в ответ на текущий набор интересующих производителей, как ранее описано. В одном варианте осуществления изобретения, ключ производителя состоит из ключа класса, ключа экземпляра и ключа метода. Как часть этого создания экземпляра производителей, модуль 1040 автоматического формирования графов производителей: 1) осуществляет доступ к структуре 1092 отслеживания классов с помощью ключа класса, чтобы осуществлять доступ к соответствующему классу из классов 1054; 2) осуществляет доступ к структуре 1065 отслеживания экземпляров с помощью ключа экземпляра, чтобы осуществлять доступ к соответствующему экземпляру из экземпляров 1052; и 3) осуществляет доступ к структуре отслеживания методов с помощью ключа метода, чтобы осуществлять доступ к соответствующему оператору объявления зависимостей производителя. Создание экземпляра производителей, обозначенных посредством команд создания экземпляра производителя, с помощью ключей 1025 производителей и создание экземпляра любых обнаруженных производителей и построение графа производителей проиллюстрировано посредством структуры 1060 графа(ов) производителей среды 1004 выполнения. Таким образом, в одном варианте осуществления изобретения, ключи производителей, идентифицированные посредством команд создания экземпляра производителя с помощью ключей 1025 производителей и обнаруженные через формирование графа производителей, сохраняются в структуре 1060 графа(ов) производителей наряду с дополнительной информацией, чтобы представлять текущий граф(ы) производителей.

Как ранее описано, этап 1095 и 1098 может быть частью этапа 1040, и, таким образом, решение, касающееся того, какие классы, экземпляры и производителей следует загружать/создавать экземпляры, направляется посредством того, какие производители находятся в текущем графе(ах) производителей. В таком варианте осуществления изобретения, загрузка/создание экземпляров классов, экземпляров и производителей оптимизируется и ориентирована на производителей.

Клиент 1002 среды выполнения также включает в себя команды подготовки данных, включая команды 1030 подмены/отмены подмены вывода производителя. Команды подмены/отмены подмены включают в себя ключ производителя, который должен быть подменен/отмена подмены которого должна быть выполнена, а также значения подмены при подмене. Модуль 1045 вывода подмененных производителей среды 1004 выполнения инструктирует подмену/отмены подмены производителей, обозначенных посредством команд подмену/отмены подмены производителя. Эта причинно-следственная зависимость может быть косвенной или прямой.

В случае косвенной причинно-следственной зависимости, модуль 1045 вывода подмененных производителей заполняет журнал 1047 регистрации подмены для использования посредством модуля 1070 выполнения графа производителей. В случае прямой причинно-следственной зависимости, модуль 1045 вывода подмененных производителей осуществляет доступ к кэшированию 1097 выводов производителя структуры 1060 графа(ов) производителей и экземплярам 1052. В частности, как описано в отношении модуля 390 вывода подмененных производителей, в одном варианте осуществления, производители могут быть классифицированы как производители свойств или производители методов; таким образом, модуль 1045 вывода подмененных производителей может включать в себя модуль вывода подмененных производителей свойств для подмененных производителей свойств и модуль вывода подмененных производителей методов для подмененных производителей методов (не показаны); подмена метода свойств инструктирует сохранение подмененного значения в кэшировании 1097 выводов производителя структуры 1060 графа(ов) производителей и сохранение в данных соответствующего экземпляра из экземпляров 1052, тогда как подмена производителя метода инструктирует сохранение подмененного значения в кэшировании 1097 выводов производителя.

В одном варианте осуществления изобретения, производители могут не подменяться до того, как граф производителей, частью которого они являются, первоначально выполнен (таким образом, экземпляр производителя уже создан в результате обозначения как интересующего производителя или в результате обнаружения посредством модуля 1040 автоматического формирования графов производителей). Тем не менее, в варианте осуществления, показанном на фиг. 10, производители могут быть подменены перед начальным выполнением посредством создания экземпляра и подмены с помощью команды подмены производителя. Такой подмененный производитель типично должен, в конечном счете, становиться частью графа производителей через процесс обнаружения (к примеру, когда динамическая зависимость разрешается). В некоторых вариантах осуществления изобретения, эта подготовка данных также может включать в себя другие типы команд задания. Модуль 1045 вывода подмененных производителей показывается как пунктирный прямоугольник, поскольку он может отсутствовать в альтернативных вариантах осуществления изобретения.

Структура 1060 графа(ов) производителей также необязательно включает в себя маркировку 1080 инкрементного выполнения для некоторых вариантов осуществления изобретения, которые поддерживают инкрементное выполнение. Как ранее описано в отношении маркировки 382 инкрементного выполнения по фиг. 3B, маркировка 1080 инкрементного выполнения используется для того, чтобы помогать при инкрементном выполнении графа(ов) производителей помимо начального выполнения. Различные варианты осуществления изобретения, которые используют маркировку 382 инкрементного выполнения, используют ее по-разному. Например, в одном таком варианте осуществления изобретения, который имеет журнал регистрации команд, журнал регистрации используется для того, чтобы отслеживать то, какие производители добавлены и/или модифицированы, и маркировка 382 инкрементного выполнения используется для того, чтобы отмечать тех производителей, которые затрагиваются (предков модифицированных или добавленных производителей и таким образом зависимых от них). В качестве еще одного примера, в одном таком варианте осуществления изобретения, который не имеет журнала регистрации команд, маркировка 382 инкрементного выполнения используется для того, чтобы отмечать тех производителей, которые добавлены или модифицированы, а также тех производителей, которые являются предками модифицированных или добавленных производителей (и таким образом зависимы от них). В качестве еще одного примера, в одном таком варианте осуществления изобретения, который не имеет журнала регистрации команд, модификации и добавления производителей осуществляются немедленно, и маркировка 382 инкрементного выполнения используется для того, чтобы отмечать тех производителей, которые являются предками модифицированных или добавленных производителей (и таким образом зависимы от них). Хотя описаны варианты осуществления изобретения, которые поддерживают инкрементное выполнение и используют маркировку инкрементного выполнения, другие варианты осуществления изобретения поддерживают инкрементное выполнение, которое не использует маркировку инкрементного выполнения (к примеру, журнал регистрации команд используется для того, чтобы отслеживать то, какие производители добавлены или модифицированы, и список производителей начала выполнения хранится в журнале регистрации начала выполнения, когда модуль 1070 выполнения графа производителей начинает с производителей начала выполнения и выполняет операции вплоть до предков графа(ов) производителей наверху; в качестве примера, а не ограничения, этот вариант осуществления изобретения описан далее в данном документе относительно фиг. 15-25.

Клиент 1002 среды выполнения также включает в себя команды 1035 глобального выполнения. Модуль 1070 выполнения графа производителей среды 1004 выполнения выполняет граф(ы) производителей. По сути, модуль 1070 выполнения графа производителей модифицирует кэширование 1097 выводов производителей (в случае производителей свойств и производителей методов), использует маркировку 1080 инкрементного выполнения (если присутствует) и модифицирует данные экземпляров 1052 (в случае методов свойств). Различные методики для выполнения производителей графа производителей ранее пояснены и применимы здесь. Например, в вариантах осуществления, в которых реализуется журнал регистрации команд, журнал регистрации команд используется, а затем граф(ы) производителей выполняются. Дополнительно, в вариантах осуществления изобретения, которые поддерживают возможность неразрешенных зависимостей, модуль 1070 выполнения графа производителей включает в себя модуль 1075 динамических зависимостей, который может активировать модуль 1040 автоматического формирования графов производителей.

Фиг. 10 также показывает необязательный модуль 1062 просмотра графов производителей, который предоставляет механизм (к примеру, графический пользовательский интерфейс), посредством которого программист/пользователь может просматривать граф(ы) производителей и выводы производителя структуры графа(ов) производителей. Дополнительно, фиг. 10 показывает необязательный конфигурируемый интерактивный модуль 1085 графического пользовательского интерфейса формата вывода производителя, чтобы предоставлять графический пользовательский интерфейс (включая динамический вызов этапов 1030 и 1035), который представляет конфигурируемый интерактивный модуль 840 графического пользовательского интерфейса формата вывода производителя.

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

Примерные структуры отслеживания

Фиг. 11A-D - это блок-схемы, иллюстрирующие примерное содержимое структур данных по фиг. 10 согласно одному варианту осуществления изобретения. Хотя фиг. 11A-D иллюстрируют эти структуры данных как таблицы, следует понимать, что может использоваться любая подходящая структура данных (к примеру, хэш-таблица, набор, список и т.д.).

Фиг. 11A - это блок-схема примера структуры 1092 отслеживания классов по фиг. 10 согласно одному варианту осуществления изобретения. На фиг. 11A, столбец 1110 ключей классов и столбец 1115 ссылок на классы показываются, чтобы, соответственно, сохранять ключи классов и соответствующие ссылки на загруженные классы.

Фиг. 11B - это блок-схема примера структуры 1065 отслеживания экземпляров по фиг. 10 согласно одному варианту осуществления изобретения. На фиг. 11B, столбец 1120 ключей экземпляров и столбец 1125 ссылок на экземпляры показываются, чтобы, соответственно, сохранять ключи экземпляров и соответствующие ссылки на экземпляры. В вариантах осуществления изобретения, в которых ключи экземпляров не должны быть уникальными по всем классам, структура отслеживания экземпляров также включает в себя ключ класса или ссылку для класса экземпляра.

Фиг. 11C - это блок-схема примера структуры 1060 графа(ов) производителей по фиг. 10 согласно одному варианту осуществления изобретения. На фиг. 11C, столбец 1135 ссылок на классы, столбец 1140 ссылок на экземпляры и столбец 1145 ссылок на методы показываются, чтобы, соответственно, сохранять ссылки, которые составляют текущие производители текущего графа(ов) производителей. Эти ссылки могут принимать множество форм. Например, эти столбцы могут, соответственно, сохранять ссылки в классы 1054 (или альтернативно 1092), экземпляры 1052 (или альтернативно 1065) и методы 1056 (или альтернативно 1058). Хотя в одном варианте осуществления изобретения эти столбцы сохраняют ссылки, в альтернативном варианте осуществления изобретения один или более из этих ключей сохраняют столбцы.

Помимо этого, фиг. 11C включает в себя столбец 1150 ссылки(ок) на родительский производитель(ей) (включая для каждой связи ссылку на родительский производитель и ссылку на производителя определения зависимостей) и столбец 1160 ссылки(ок) на дочерний производитель(ей) (включая для каждой связи ссылку(и) на дочерний производитель, ссылку на производителя определения зависимостей, режим связывания и индикатор прикрепляющей связи). Каждый производитель может иметь нуль или более связей дочерних производителей в столбце 1160. Каждая связь дочернего производителя в столбце 1160 включает в себя: 1) ссылку(ки) на дочерний производитель, которая является ссылкой на другие строки структуры графа(ов) производителей, чтобы представлять зависимость производителя согласно объявлению зависимостей производителя; 2) ссылку на производителя определения зависимостей, которая является ссылкой на другую строку структуры графа(ов) производителей и представляет производитель определения зависимостей, который создал дочернюю связь; и 3) режим связывания с типом зависимости производителя, который идентифицирует то, является ли зависимость производителя результатом зависимости аргументов, полей или упорядочения (см. пояснения относительно фиг. 7A-F), и если аргумента, идентификатор аргумента зависимости производителя; и 4) индикатор прикрепления, чтобы указывать то, что режим связывания - это результат восходяще объявляемой зависимости (в вариантах осуществления изобретения, которые поддерживают восходяще объявляемые зависимости) или результат прикрепляющей подписки (в вариантах осуществления изобретения, которые поддерживают прикрепляющие подписки), и он не должен модифицироваться через объявление зависимости аргументов производителя этого производителя (т.е. производителя, сохраненного в строке столбца, содержащего индикатор прикрепления). Каждый производитель может иметь нуль или более связей родительских производителей в столбце 1150. Каждая связь родительского производителя в столбце 1150 включает в себя: 1) ссылку на родительской производитель, которая сохраняет ссылку в соответствии со ссылкой на дочерний производитель другого производителя (т.е. ссылку на другую строку структуры графа(ов) производителей, чтобы представлять родительский производитель, зависимый от этого производителя); и 2) ссылку на производителя определения зависимостей, которая является ссылкой на другую строку структуры графа(ов) производителей и представляет производитель определения зависимостей, который создал родительскую связь. Таким образом, когда связь создана, столбец связей родительских производителей строки дочернего производителя и столбец связей дочерних производителей строки родительского производителя модифицируются так, чтобы представлять связь (и ссылка на производителя определения зависимостей является одинаковой в обоих случаях). В одном варианте осуществления изобретения, поскольку несколько путей на графе производителей или различных графах производителей могут включать в себя данного производителя, может быть несколько ссылок на родительский производитель для данного производителя.

Дополнительно, фиг. 11C включает в себя кэширование выводов производителя и столбец 1170 модификации вывода подмененных производителей, чтобы сохранять текущие выводы производителя, а также индикатор относительно того, подменен ли производитель, и подмененное выходное значение. Кроме этого, фиг. 11C включает в себя столбец 1180 маркировки инкрементного выполнения, чтобы сохранять маркировки инкрементного выполнения, как ранее описано.

Фиг. 11D - это блок-схема примера структуры 1058 отслеживания методов по фиг. 10 согласно одному варианту осуществления изобретения. На фиг. 11A, столбец 1190 ключей методов и столбец 1192 ссылок на методы показываются, чтобы, соответственно, сохранять ключи методов и соответствующие ссылки на методы загруженных классов. Помимо этого, фиг. 11D также включает в себя столбец 1194 ArgumentDependencies, столбец 1196 FieldDependencies, столбец 1195 SequencingDependencies, столбец 1193 UpwardDependencies, столбец 1199 WeaklyConstrainedDependencies, столбец 1197 выходных классов и необязательный столбец 1198 дополнительных примечаний. Столбец 1194 ArgumentDependencies, столбец 1195 SequencingDependencies, столбец 1193 UpwardDependencies, столбец 1199 WeaklyConstrainedDependencies и столбец 1196 FieldDependencies хранят информацию зависимости производителя, синтаксически проанализированную из оператора объявления зависимостей производителя метода (к примеру, см. 705 по фиг. 7A), тогда как столбец выходных классов 1197 хранит информацию, касающуюся выходного класса вывода метода (определяемого посредством подписи метода - к примеру, см. 710 по фиг. 7A). Примерное содержимое столбца 1194 ArgumentDependencies, столбца 1196 FieldDependencies, столбца 1195 SequencingDependencies, столбца 1193 UpwardDependency и столбца 1199 WeaklyConstrainedDependencies, используемого в некоторых вариантах осуществления изобретения, предоставляется далее в данном документе.

Динамические зависимости производителя

Как ранее описано, один вариант осуществления изобретения поддерживает нединамические и динамические зависимости производителя. Хотя различные варианты осуществления могут поддерживать различные типы динамических зависимостей производителя, один вариант осуществления изобретения поддерживает условные и подписные типы динамических зависимостей производителя. Таким образом, безусловная, неподписная зависимость - это нединамическая (статическая) зависимость.

Фиг. 12 - это блок-схема, иллюстрирующая дополнительные детали фиг. 10, чтобы поддерживать условные и подписные типы динамических зависимостей производителя согласно одному варианту осуществления изобретения. Фиг. 12 включает из фиг. 10 пунктирную разделительную линию 1000, определения классов, которые включают в себя бизнес-логику 1010 (которая включает в себя данные 1012, методы 1014 и объявления 1016 зависимостей производителя), модуль 1095 создания классов, классы 1054 (включающие в себя методы и объявления 1056 зависимостей производителя), модуль 1098 создания экземпляров, экземпляры 1052, структуру 1065 отслеживания экземпляров, модуль 1040 автоматического формирования графов производителей, структуру 1060 графа(ов) производителей и модуль 1070 выполнения графа производителей (включающий в себя модуль 1075 динамических зависимостей).

Фиг. 12 показывает то, что объявления 1016 зависимостей производителя необязательно включают в себя условные зависимости 1210, подписные зависимости 1220 и несколько производителей 1215. Здесь, несколько производителей 1215 упоминаются как возможность зависимости производителя возвращать совокупность производителей. Помимо этого, фиг. 12 включает в себя подписной модуль 1240 и условный модуль 1230 в модуле 1040 автоматического формирования графов производителей, чтобы обрабатывать условные зависимости 1210 и подписные зависимости 1220. Фиг. 12 также показывает то, что подписной модуль 1240 осуществляет доступ к журналу 1250 регистрации подписок. Дополнительно, модуль 1075 динамических зависимостей включает в себя условный модуль 1260 и подписной модуль 1265, чтобы обрабатывать условные зависимости 1210 и подписные зависимости 1220. Подписной модуль 1265 осуществляет доступ к журналу 1250 регистрации подписок.

Нижеследующее описание условных и подписных зависимостей осуществляется в контексте варианта осуществления изобретения, который использует класс DEP (сокращение для зависимости), который возвращается посредством производителей определения зависимостей и анализируется посредством среды выполнения со средствами поддержки графоориентированного программирования на основе производителей. Класс DEP включает в себя следующие поля: 1) TYPE, которое может быть задано равным подписным, неподписным нисходяще объявляемым (дочерним производителям, которые не являются подписками) или неподписным восходяще объявляемым (родительским производителям, которые не являются подписками); 2) PROD, которое используется для неподписных нисходяще объявляемых зависимостей и является совокупностью дочерних производителей (также, оно может сохранять нуль или более производителей); 3) SUB TYPE, которое используется для подписных зависимостей и задается так, чтобы указывать тип подписной зависимости (используемой в вариантах осуществления изобретения, которые поддерживают несколько типов подписки; в то время как вариант осуществления изобретения, описанный здесь, поддерживает два типа - прикрепляющие и поглощающие, альтернативные варианты осуществления могут поддерживать больше, меньше и/или другие типы подписок; 4) SUB CRIT, которое используется для подписных зависимостей и задан так, чтобы указывать критерии подписки; 5) PAR LINK MODE, которое используется для зависимостей типа прикрепляющей подписки и неподписных восходяще объявляемых зависимостей и задается так, чтобы указывать то, каким должен быть режим связывания родительского производителя; 6) PAR CLASS, которое используется для зависимостей на основе прикрепляющей подписки и неподписных восходяще объявляемых зависимостей и задается так, чтобы указывать то, каким должен быть класс родительского производителя (к примеру, ключ класса); 7) PAR METHOD, которое используется для зависимостей на основе прикрепляющей подписки и неподписных восходяще объявляемых зависимостей и задается так, чтобы указывать то, каким должен быть метод родительского производителя (к примеру, ключ метода); и 8) PAR INSTANCE, которое используется для зависимостей на основе прикрепляющей подписки и неподписных восходяще объявляемых зависимостей и задается так, чтобы указывать то, каким должен быть экземпляр родительского производителя (к примеру, ключ экземпляра) (если PAR INSTANCE оставляется пустым, ключ экземпляра дочернего производителя в таком случае используется для родительского производителя). Альтернативный вариант осуществления может использовать совокупность родительских производителей (каждый элемент совокупности хранит PAR _CLASS, PAR _INSTANCE, PAR _METHOD, PAR_LINK_MODE) в случае зависимостей на основе прикрепляющей подписки и/или неподписных восходяще объявляемых зависимостей. Конечно, другие альтернативные варианты осуществления изобретения могут использовать другую структуру для того, чтобы возвращать зависимости.

Условные зависимости

В одном варианте осуществления изобретения поддерживаются как безусловные, так и условные зависимости производителя. Безусловная зависимость производителя - это зависимость, которая является независимой от вывода других производителей, тогда как условная зависимость производителя - это зависимость, которая зависит от вывода других производителей. Хотя один вариант осуществления изобретения поддерживает как безусловные, так и условные зависимости производителя, альтернативные варианты осуществления поддерживают только безусловные или условные (причем условные зависимости производителя могут первоначально направляться посредством значений по умолчанию).

Как пояснено ранее, производитель может рассматриваться как набор из нескольких идентификаторов, по одному идентификатору для каждого дополнительного уровня указанной степени детализации. В одном варианте осуществления изобретения, условная зависимость производителя может быть условной в том смысле, что любой или все из набора идентификаторов могут быть условно определены на основе текущих значений данных. Например, первая условная зависимость производителя может иметь только идентификатор экземпляра условно определяемым (идентификаторы классов и методов являются фиксированными), тогда как вторая условная зависимость производителя может иметь идентификаторы классов, экземпляров и методов условно определяемыми. Хотя в одном варианте осуществления изобретения все из множества идентификаторов условной зависимости производителя могут быть условными, альтернативные варианты осуществления изобретения могут быть реализованы по-другому (к примеру, давать возможность только поднабору из множества идентификаторов быть условным).

Фиг. 13A-J - это блок-схемы, иллюстрирующие псевдокод и примерных производителей согласно одному варианту осуществления изобретения. Помимо этого, варианты осуществления, показанные на фиг. 13A-J, используют одинаковый механизм определения зависимости как для условных, так и для безусловных зависимостей. По сути, в целях пояснения, некоторые из примеров на фиг. 13A-J являются примерами безусловных зависимостей, тогда как другие являются примерами условных зависимостей производителя. Дополнительно, безусловная зависимость производителя - это зависимость, в которой зависимость идет к производителю определения зависимостей, который является независимым производителем (к примеру, в одном варианте осуществления изобретения, тип зависимости является идентифицируемым, поскольку его объявление зависимостей производителя является пустым); тогда как условная зависимость производителя - это зависимость, в которой зависимость идет к производителю определения зависимостей, который является зависимым производителем (к примеру, в одном варианте осуществления изобретения, тип зависимости является идентифицируемым, поскольку его объявление зависимостей производителя является непустым).

Дополнительно, цифры и символы в кружках используются на фиг. 13A-J для того, чтобы иллюстрировать порядок, в котором операции выполняются согласно одному варианту осуществления изобретения. Кроме этого, нотация X::Y::Z используется на фиг. 13A-J для того, чтобы представлять ключ производителя, составленный из ключа класса (X), ключа экземпляра (Y) и ключа метода (Z). Дополнительно, пунктирные круги и линии со стрелками представляют операции, которые не выполняются в некоторых вариантах осуществления изобретения. В частности, если выполнение независимого производителя определения зависимостей для данной зависимости должно всегда возвращать одну и ту же зависимость (к примеру, независимый производитель определения зависимостей), такой производитель определения зависимостей в некоторых вариантах осуществления изобретения выполняется, но его экземпляр не создается, и он не связывается на графе(ах) производителей.

Производители определения явных зависимостей

Фиг. 13A иллюстрирует псевдокод объявлений зависимостей производителя для методов, использующих несокращенную объявленную, нединамическую (безусловную, неподписную) зависимость согласно одному варианту осуществления изобретения; тогда как фиг. 13B - это блок-схема производителей, иллюстрирующая примерную несокращенную объявленную, нединамическую (безусловную, неподписную) зависимость производителя согласно одному варианту осуществления изобретения. Фиг. 13A показывает: 1) оператор 1300 объявления зависимостей производителя для метода альфа 1305, причем оператор 1300 объявления зависимостей производителя включает в себя зависимость производителя для производителя CW::IY::BETA; и 2) оператор 1310 объявления зависимостей производителя для метода бета 1315, при этом оператор 1310 объявления зависимостей производителя является пустым, и при этом метод бета 1315 возвращает в качестве аргумента экземпляр класса DEP. Метод бета 1315 включает в себя код 1320 объявления зависимостей производителя, который задает DEP.TYPE как неподписной нисходяще объявляемый, задает DEP.PROD как производитель 13 и возвращает DEP.

На фиг. 13A, 1 в кружке указывает то, что к объявлению 1300 зависимостей производителя осуществляется доступ (к примеру, в результате обозначения производителя на основе метода альфа 1305 как интересующего производителя, в результате автоматического обнаружения производителя на основе метода альфа 1305 как потомства интересующего производителя и т.д.). 2 в кружке на фиг. 13B показывает то, что создается экземпляр производителя C0::I0::ALPHA на основе метода альфа 1305. 3 в кружке на фиг. 13A указывает то, что зависимость производителя для производителя CW::IY::BETA обрабатывается так, чтобы определять зависимость производителя, и как результат, 4 в кружке указывает то, что к объявлению 1310 зависимостей производителя осуществляется доступ. 5 в пунктирном кружке на фиг. 13B показывает, что создается экземпляр производителя CW::IY::BETA как производитель 1380 определения зависимостей. 6 в пунктирном кружке на фиг. 13B указывает то, что производитель C0::I0::ALPHA связывается на графе производителей так, чтобы указывать то, что производитель CW::IY::BETA является дочерним производителем. 7 в кружке на фиг. 13B указывает то, что производитель CW::IY::BETA выполняется и возвращает DEP, чтобы идентифицировать производителя 13. 8 в кружке указывает то, что создается экземпляр производителя 13, тогда как 9 в кружке указывает производителя 13, связываемого как дочерний производитель на графе производителей с производителем C0::I0::ALPHA. На фиг. 13B, производитель C0::I0::ALPHA и производитель 13 являются стандартными производителями 1385 (они не являются производителями определения зависимостей).

Фиг. 13C иллюстрирует псевдокод объявлений зависимостей производителя для методов, использующих несокращенную объявленную, условную, неподписную зависимость производителя согласно одному варианту осуществления изобретения; тогда как фиг. 13D - это блок-схема производителей, иллюстрирующая примерную несокращенную объявленную, условную, неподписную зависимость производителя согласно одному варианту осуществления изобретения. Помимо этого, фиг. 13D ссылается на производителей 5, 7A и 7B по фиг. 5A и разрешение динамической зависимости производителя 5 к производителю 7A.

Фиг. 13C показывает: 1) оператор 1300 объявления зависимостей производителя для метода альфа 1305, причем оператор 1300 объявления зависимостей производителя включает в себя зависимость производителя для производителя CW::IY::BETA; 2) оператор 1325 объявления зависимостей производителя для метода бета 1315, при этом оператор 1325 объявления зависимостей производителя включает в себя зависимость производителя для производителя CU::IV::DELTA, и при этом метод бета 1315 возвращает в качестве аргумента экземпляр класса DEP; 3) оператор 1332 объявления зависимостей производителя для метода дельта 1334, при этом оператор 1332 объявления зависимостей производителя является пустым, и при этом метод дельта 1334 возвращает в качестве аргумента экземпляр класса DEP; и 4) оператор 1338 объявления зависимостей производителя для метода гамма 1340, при этом оператор 1338 объявления зависимостей производителя является пустым, и при этом метод гамма 1340 возвращает переменную X (при этом X исходит из внешнего источника, значением по умолчанию (явным или постоянным в классе). Метод бета 1315 включает в себя код 1330 объявления зависимостей производителя, который задает DEP.TYPE как неподписную нисходяще объявляемую, задает DEP.PROD как производителя 7A или 7B в зависимости от вывода производителя CX::IZ::GAMMA и возвращает DEP. Метод дельта 1332 включает в себя код 1336 объявления зависимостей производителя, который задает DEP.TYPE как неподписную нисходяще объявляемую, задает DEP.PROD как производителя CX::IZ::GAMMA и возвращает DEP.PROD.

На фиг. 13С, 1 в кружке указывает то, что к объявлению 1300 зависимостей производителя осуществляется доступ (к примеру, в результате обозначения производителя на основе метода альфа 1305 как интересующего производителя, в результате автоматического обнаружения производителя на основе метода альфа 1305 как потомства интересующего производителя и т.д.). 2 в кружке на фиг. 13D показывает то, что создается экземпляр производителя 5 на основе метода альфа 1305. 3 в кружке на фиг. 13C указывает то, что зависимость производителя для производителя CW::IY::BETA обрабатывается так, чтобы определять зависимость производителя, и, как результат, 4 в кружке указывает то, что к объявлению 1325 зависимостей производителя осуществляется доступ. 5 в кружке на фиг. 13D показывает то, что создается экземпляр производителя CW::IY::BETA как производителя 1380 определения зависимостей. 6 в кружке на фиг. 13D указывает то, что производитель 5 связывается на графе производителей так, чтобы указывать то, что производитель CW::IY::BETA является дочерним производителем.

7 в кружке на фиг. 13C указывает то, что зависимость производителя для производителя CU::IV::DELTA обрабатывается так, чтобы определять зависимость производителя, и, как результат, 8 в кружке указывает то, что к объявлению 1332 зависимостей производителя осуществляется доступ. 9 в пунктирном кружке на фиг. 13D показывает то, что создается экземпляр производителя CU::IV::DELTA как производитель 1380 определения зависимостей. 10 в пунктирном кружке на фиг. 13D указывает то, что производитель CW::IY::BETA связывается на графе производителей так, чтобы указывать то, что производитель CU::IV::DELTA является дочерним производителем. 11 в кружке на фиг. 13D указывает то, что производитель CU::IV::DELTA выполняется и возвращает DEP, чтобы идентифицировать CX::IZ::GAMMA. 12 в кружке указывает то, что создается экземпляр производителя CX::IZ::GAMMA, тогда как 13 в кружке указывает то, что производитель CX::IZ::GAMMA связывается как дочерний производитель на графе производителей с производителем CW::IY::BETA.

На фиг. 13D, A в кружке указывает то, что производитель CX::IZ::GAMMA выполняется и возвращает X в производитель CW::IY::BETA, тогда как B в кружке указывает то, что производитель CW::IY::BETA возвращает DEP, чтобы идентифицировать производителя 7A; C в кружке указывает то, что неразрешенная оставшаяся часть (метод бета 1390) теперь разрешена, и создается экземпляр производителя 7A, тогда как D в кружке указывает связывание производителя 5 с производителем 7A. На фиг. 13D, производители CX::IZ::GAMMA, 5 и 7A являются стандартными производителями 1385.

Производители определения зависимостей "на лету"

Фиг. 13E иллюстрирует псевдокод объявлений зависимостей производителя для методов, использующих как несокращенную объявленную, условную, неподписную зависимость производителя, так и сокращенную объявленную, условную, неподписную зависимость производителя согласно одному варианту осуществления изобретения; тогда как фиг. 13F - это блок-схема производителей, иллюстрирующая несокращенную объявленную, условную, неподписную зависимость производителя и сокращенную, условную объявленную, неподписную зависимость производителя согласно одному варианту осуществления изобретения. Аналогично фиг. 13D, фиг. 13F ссылается на производителей 5, 7A и 7B по фиг. 5A и разрешение динамической зависимости производителя 5 к производителю 7A.

Фиг. 13E-F являются такими же, как фиг. 13C-D, со следующими исключениями: 1) оператор 1342 объявления зависимостей производителя заменяет оператора 1325 объявления зависимостей производителя; 2) метод fly 1344 заменяет метод дельта 1334; и 3) производитель CW::IY::FLY заменяет производителя CU::IV::DELTA. Оператор 1342 объявления зависимостей производителя включает в себя сокращенную объявленную зависимость производителя для CX::IZ::GAMMA. Таким образом, 4 в кружке на фиг. 13E теперь указывает то, что к объявлению зависимостей производителя 1342 осуществляется доступ. 7 в кружке на фиг. 13E теперь указывает то, что сокращенная объявленная зависимость производителя для производителя CX::IZ::GAMMA обрабатывается так, чтобы определять зависимость производителя, и, как результат, среда выполнения активирует производитель определения зависимостей CW::IY::FLY "на лету" на основе метода fly 1344. 8 в кружке теперь указывает то, что к объявлению 1332 зависимостей производителя осуществляется доступ. 9 в пунктирном кружке на фиг. 13F теперь показывает то, что создается экземпляр производителя CW::IY::FLY. 10 в пунктирном кружке на фиг. 13F указывает то, что производитель CW::IY::BETA связывается на графе производителей так, чтобы указывать то, что производитель CW::IY::FLY является дочерним производителем. 11 в кружке на фиг. 13F указывает то, что производитель CW::IY::FLY выполняется и возвращает DEP, чтобы идентифицировать CX::IZ::GAMMA. Оставшаяся часть фиг. 13E-F является такой же, как фиг. 13C-D.

Формирование "на лету" посредством среды выполнения производителя определения зависимостей CW::IY::FLY освобождает прикладного программиста от необходимости писать явный код объявления зависимостей производителя и создавать экземпляр производителя определения зависимостей на основе него. Дополнительно, это дает возможность прикладному программисту указывать зависимость производителя CX::IZ::GAMMA непосредственно в операторе объявления зависимостей производителя для метода бета 1315, в противоположность указанию производителя определения зависимостей CU::IV::DELTA.

Сокращенная методика может использоваться во множестве ситуаций и дополнительно может иметь множество форматов. Например, хотя на фиг. 13E-F сокращенная объявленная зависимость является безусловной зависимостью (она непосредственно идентифицирует дочерний производитель) и находится в операторе объявления зависимостей производителя для метода, на котором основан производитель определения зависимостей, другие ситуации и форматы показываются следующим образом: 1) фиг. 13G-H иллюстрируют использование двух сокращенных элементов, где один является условным и является частью оператора объявления зависимостей производителя для метода, на котором основан стандартный производитель, а другой является безусловным и является частью оператора объявления зависимостей производителя для метода, на котором основан производитель определения зависимостей; и 2) фиг. I-J иллюстрируют использование сокращенного элемента, который является безусловным и который находится в операторе объявления зависимостей производителя для метода, на котором основан родительский стандартный производитель.

Фиг. 13G иллюстрирует псевдокод объявлений зависимостей производителя для методов, используя сокращенную объявленную, условную, неподписную зависимость производителя и сокращенную объявленную, безусловную, неподписную зависимость производителя согласно одному варианту осуществления изобретения; тогда как фиг. 13H - это блок-схема производителей, иллюстрирующая примерную сокращенную объявленную, условную, неподписную зависимость производителя и сокращенную объявленную, безусловную, неподписную зависимость производителя согласно одному варианту осуществления изобретения. Фиг. 13G показывает: 1) оператор 1345 объявления зависимостей производителя для метода альфа 1305, при этом оператор 1345 объявления зависимостей производителя включает в себя сокращенную объявленную, условную зависимость производителя к производителю GETC1::I1::M1; 2) оператор 1350 объявления зависимостей производителя для метода fly1 1355, при этом оператор 1350 объявления зависимостей производителя включает в себя сокращенную объявленную, безусловную зависимость производителя для производителя C0:I0::GETC1 и при этом метод fly1 1355 возвращает в качестве аргумента экземпляр DEP; 3) оператор 1332 объявления зависимостей производителя для метода fly2 1362, при этом метод fly2 1362 возвращает в качестве аргумента экземпляр DEP; и 4) оператор 1365 объявления зависимостей производителя для метода getc1 1370, при этом метод getc1 1370 возвращает C1 со значением CX или CY.

Метод fly1 1355 и его оператор 1350 объявления зависимостей производителя предоставляются посредством среды выполнения в ответ на сокращенную объявленную зависимость GETC1::I1::M1 (который указывает то, что сокращенная используется для ключа класса). Метод fly1 1355 включает в себя код 1360 объявления зависимостей производителя, который задает DEP.TYPE как неподписную нисходяще объявляемую, задает DEP.PROD как производитель CX::I1::M1 или CY::I1::M1 в зависимости от значения C1, выводимого посредством производителя C0:I0::GETC1, и возвращает DEP. Хотя в примере по фиг. 13H используется для того, чтобы обозначать, что это - ключ класса производителя, который является условным, альтернативные варианты осуществления изобретения могут использовать другие синтаксисы. Дополнительно, хотя в примере по фиг. 13H используется для того, чтобы обозначать то, что это - ключ класса производителя, который является условным, один вариант осуществления изобретения поддерживает имеющие больше и/или другие идентификаторы, которые составляют ключ производителя быть указанными как условные этим способом.

На фиг. 13G, 1 в кружке указывает то, что к объявлению 1345 зависимостей производителя осуществляется доступ (к примеру, в результате обозначения производителя на основе метода альфа 1305 как интересующего производителя, в результате автоматического обнаружения производителя на основе метода альфа 1305 как потомства интересующего производителя и т.д.). 2 в кружке на фиг. 13H показывает то, что создается экземпляр производителя C0::I0::ALPHA на основе метода альфа 1305. 3 в кружке на фиг. 13G указывает то, что сокращенная объявленная зависимость производителя обрабатывается, чтобы определять зависимость производителя, и среда выполнения предоставляет метод fly1 1355; и, как результат, 4 в кружке указывает то, что к объявлению 1350 зависимостей производителя осуществляется доступ.

5 в кружке на фиг. 13H показывает то, что создается экземпляр производителя C0::I0::FLY1 как производитель 1380 определения зависимостей. 6 в кружке на фиг. 13H указывает то, что производитель C0::I0::ALPHA связывается на графе производителей так, чтобы указывать то, что производитель C0::I0::FLY1 является дочерним производителем. 7 в кружке на фиг. 13G указывает то, что сокращенная объявленная зависимость производителя для производителя C0:I0::GETC1 обрабатывается так, чтобы определять зависимость производителя, и среда выполнения предоставляет метод fly2 1362, и, как результат, 8 в кружке указывает то, что к объявлению 1332 зависимостей производителя осуществляется доступ. 9 в пунктирном кружке на фиг. 13H показывает то, что создается экземпляр производителя C0::I0::FLY2. 10 в пунктирном кружке на фиг. 13H указывает то, что производитель C0::I0::FLY1 связывается на графе производителей так, чтобы указывать то, что производитель C0::I0::FLY2 является дочерним производителем.

11 в кружке на фиг. 13H указывает то, что производитель C0::I0::FLY2 выполняется и возвращает DEP, чтобы идентифицировать производителя C0:I0::GETC1. 12 в кружке указывает то, что создается экземпляр производителя C0:I0::GETC1, тогда как 13 в кружке указывает то, что производитель C0:I0::GETC1 связывается на графе производителей с производителем C0::I0::FLY1 как дочерний производитель.

На фиг. 13H, A в кружке указывает то, что производитель C0:I0::GETC1 выполняется и возвращает C1=CX в производитель C0::I0::FLY1, тогда как B в кружке указывает то, что производитель C0::I0::FLY1 выполняется и возвращает DEP, чтобы идентифицировать производителя CX::I1::M1; C в кружке указывает то, что неразрешенная оставшаяся часть (метод fly1) 1390 теперь разрешена, и D в кружке указывает связывание производителя C0::I0::ALPHA с производителем CX::I1::M1. На фиг. 13H, производители C0:I0::GETC1, C0::I0::ALPHA и CX::I1::M1 являются стандартными производителями 1385.

Формирование "на лету" посредством среды выполнения производителя определения зависимостей C0::I0::FLY1 и C0::I0::FLY2 освобождает прикладного программиста от необходимости писать явный код объявления зависимостей производителя и создавать экземпляр производителей определения зависимостей на его основе. Дополнительно, это дает возможность прикладному программисту непосредственно указывать условную зависимость производителя **:: I1:: M1 через метод getc1 в операторе объявления зависимостей производителя для метода альфа 1305, в противоположность указанию производителя определения зависимостей CW::IY::BETA.

Фиг. 13I иллюстрирует псевдокод объявлений зависимостей производителя для методов, использующих сокращенную объявленную, нединамическую (безусловную, неподписную) зависимость производителя согласно одному варианту осуществления изобретения; тогда как фиг. 13J - это блок-схема производителей, иллюстрирующая примерную сокращенную объявленную, нединамическую зависимость производителя согласно одному варианту осуществления изобретения. Фиг. 13I показывает: 1) оператор 1372 объявления зависимостей производителя для метода альфа 1305, при этом оператор 1372 объявления зависимостей производителя включает в себя сокращенную объявленную зависимость производителя для производителя 10; и 2) оператор 1374 объявления зависимостей производителя для метода fly 1376, при этом оператор 1374 объявления зависимостей производителя является пустым, и при этом метод fly 1376 возвращает в качестве аргумента экземпляр DEP. Метод fly 1776 и его оператор 1374 объявления зависимостей производителя предоставляется посредством среды выполнения в ответ на сокращенную объявленную зависимость. Метод fly 1376 включает в себя код 1378 объявления зависимостей производителя, который задает DEP.TYPE как неподписную нисходяще объявляемую, задает DEP.PROD как производитель 10 и возвращает DEP.

На фиг. 13I, 1 в кружке указывает то, что к объявлению 1372 зависимостей производителя осуществляется доступ (к примеру, в результате обозначения производителя на основе метода альфа 1305 как интересующего производителя, в результате автоматического обнаружения производителя на основе метода альфа 1305 как потомства интересующего производителя и т.д.). 2 в кружке на фиг. 13J показывает то, что создается экземпляр производителя C0::I0::ALPHA на основе метода альфа 1305. 3 в кружке на фиг. 13I указывает то, что сокращенная объявленная зависимость производителя обрабатывается, чтобы определять зависимость производителя, и среда выполнения предоставляет метод fly1 1376; и как результат, 4 в кружке указывает то, что к объявлению 1374 зависимостей производителя осуществляется доступ. 5 в пунктирном кружке на фиг. 13J показывает то, что создается экземпляр производителя C0::I0::FLY как производитель 1380 определения зависимостей. 6 в пунктирном кружке на фиг. 13J указывает то, что производитель C0::I0::ALPHA связывается на графе производителей так, чтобы указывать то, что производитель C0::I0::FLY является дочерним производителем.

7 в кружке на фиг. 13J указывает то, что производитель C0::I0::FLY выполняется и возвращает DEP, чтобы идентифицировать производителя 10. 8 в кружке указывает то, что создается экземпляр производителя 10, тогда как 9 в кружке указывает производитель C0::I0::ALPHA, связываемый на графе производителей, чтобы указывать то, что производитель 10 является дочерним производителем. На фиг. 13J, производитель C0::I0::ALPHA и производитель 10 являются стандартными производителями 1385.

Следует понимать, что программист среды выполнения, в одном варианте осуществления изобретения, пишет один метод fly, чтобы интерпретировать все поддерживаемые синтаксисы и комбинации (к примеру, метод fly 1334, метод fly1 1355, метод fly2 1362, метод fly 1376), и включает его в среду выполнения. Это не только дает возможность программистам приложений исключать написание кода для производителей определения зависимостей, где метод fly может использоваться, а программист среды выполнения должен писать только универсальный метод fly (один метод fly для всех поддерживаемых ситуаций) один раз. Дополнительно, следует понимать, что сокращенные объявленные зависимости предоставляют среду выполнения, которая использует производители определения зависимостей, при этом одновременно давая возможность прикладному программисту указывать стандартных производителей в объявлениях зависимостей производителя (к примеру, фиг. 13G-J).

Структура отслеживания методов

Снова ссылаясь на структуру отслеживания методов на фиг. 11D, примерное содержимое столбца 1194 ArgumentDependencies, столбца 1196 FieldDependencies, столбца 1195 SequencingDependencies, столбца 1193 UpwardDependencies и столбца 1199 WeaklyConstrainedDependencies, используемого в некоторых вариантах осуществления изобретения, далее описано. В частности, столбец 1194 ArgumentDependencies сохраняет совокупность элементов, по одному для каждого ArgumentDependency. В одном варианте осуществления изобретения, каждый элемент включает в себя следующее: 1) идентификатор аргумента; 2) идентификатор характера ключа класса, являющийся одним из явного класса, того же класса и условного класса; 3) явный идентификатор ключа класса, заполняемый, когда идентификатор характера ключа класса указывает явный класс; 4) идентификатор ключа метода определения условных классов, заполняемый, когда идентификатор характера ключа класса указывает условный класс; 5) идентификатор характера ключа экземпляра, являющийся одним из явного экземпляра, того же экземпляра и условного экземпляра; 6) явный идентификатор ключа экземпляра, заполняемый, когда идентификатор характера ключа экземпляра указывает явный экземпляр; 7) идентификатор ключа метода определения условных экземпляров, заполняемый, когда идентификатор характера ключа экземпляра указывает условный экземпляр; 8) идентификатор характера ключа метода, являющийся одним из явного метода, того же метода и условного метода; 9) явный идентификатор ключа метода, заполняемый, когда идентификатор характера ключа метода указывает явный метод; 10) идентификатор ключа метода определения условных методов, заполняемый, когда идентификатор характера ключа метода указывает условный метод; и 11) сокращенный идентификатор, который указывает то, содержит ли объявление зависимостей производителя для аргумента в операторе объявления зависимостей производителя индикатор сокращенного (т.е. оператор объявления зависимостей производителя непосредственно идентифицирует стандартный дочерний производитель вместо производителя определения зависимостей).

Указание "...явный" различных ключевых идентификаторов характера используется, когда явный ключ предоставляется для зависимости производителя в операторе объявления зависимостей производителя. В качестве примера, зависимость производителя "CW::IY::BETA" оператора 1300 объявления зависимостей производителя по фиг. 13A предоставляет явный класс, экземпляр и ключ метода.

В некоторых вариантах осуществления изобретения, сокращенная методика поддерживается для операторов объявления зависимостей производителя так что: 1) если класс не предоставляется для данной зависимости производителя, то такой же класс, как родительский производитель, используется; и 2) если класс и экземпляр не предоставляются для данной зависимости производителя, то тот же класс и экземпляр, как родительский производитель, используются. В других вариантах осуществления изобретения, синтаксис используется для того, чтобы давать возможность любой комбинации класса, экземпляра и метода, быть такой же, как в родительском элементе (за исключением того, что все являются такими же) (к примеру, разделитель используется для того, чтобы обозначать каждый класс, экземпляр и метод, и отсутствие такого разделителя указывает такой же, как родительский - в качестве конкретного примера, синтаксис может быть "#C:", "#I: и "#M:", так что зависимость производителя в операторе объявления зависимостей производителя может быть #C:"ключ класса"::#I:"ключ экземпляра"::#M:"ключ метода"), (где кавычки указывают указатель места заполнения для значения или переменной). "... Такой же" индикатор различных ключевых идентификаторов характера используется, если эта сокращенная методика используется в операторе объявления зависимостей производителя.

Как ранее указано, в некоторых вариантах осуществления изобретения, индикатор условной зависимости производителя поддерживается через синтаксис (к примеру, ), используемый в самом операторе объявления зависимостей производителя (см. 1345 фиг. 13G), и такой синтаксис может использоваться для одного или более из класса, экземпляра и метода зависимости производителя. Указание "...условный" различных ключевых идентификаторов характера используется для того, чтобы идентифицировать, когда эта условная зависимость производителя возникает, тогда как "условный... идентификатор ключа метода определения" указывает ключ метода дочернего производителя (класс и экземпляр являются таким же, как в родительском производителе). В качестве примера, зависимость производителя "GETC1::I1::M1" для объявления 1345 зависимостей производителя по фиг. 13G предоставляет условный класс (где ключ метода определения условных классов - это GETC1), явный ключ экземпляра и явный ключ метода.

Столбец 1195 SequencingDependencies, столбец 1193 UpwardDependencies и столбец 1195 WeaklyConstrainedDependencies каждый сохраняют совокупность элементов, по одному для каждого SequencingDependency, UpwardDependency и WeaklyConstrainedDependency. В одном варианте осуществления изобретения, каждый такой элемент имеет такую же структуру, как элемент совокупности для ArgumentDependencies, за исключением того, что он не включает в себя идентификатор аргумента. Дополнительно, хотя фиг. 13A-J иллюстрируют неподписные нисходяще объявляемые зависимости, исходящие от производителей определения зависимостей, следует понимать, что в случае восходяще объявляемой зависимости или слабо ограниченной зависимости производитель определения зависимостей может возвращать другие зависимости, поясненные со ссылкой на фиг. 7F-G.

Столбец 1196 FieldDependencies сохраняет совокупность элементов, по одному для каждого FieldDependency. Хотя в одном варианте осуществления изобретения каждый элемент включает в себя ключ метода свойств, в альтернативных вариантах осуществления изобретения, может иметь такую же структуру, как элемент совокупности из SequencingDependencies.

Подписные зависимости

В одном варианте осуществления изобретения, как неподписные, так и подписные зависимости производителя поддерживаются. Когда подписная зависимость производителя объявляется для данного метода и экземпляр данного производителя создается из этого данного метода, среда выполнения может разрешать в ходе выполнения (на основе наличия других производителей) набор из нуля или более производителей, которые отвечают критериям подписки. Хотя один вариант осуществления изобретения поддерживает как неподписные, так и подписные зависимости производителя, альтернативные варианты осуществления поддерживают только неподписные. Помимо этого, хотя в одном варианте осуществления изобретения два типа подписных зависимостей поддерживаются (поглощающие и прикрепляющие), альтернативные варианты осуществления изобретения поддерживают больше, меньше и/или другие типы подписных зависимостей производителя.

Фиг. 14A-C - это блок-схемы, иллюстрирующие поглощающие и прикрепляющие подписки согласно одному варианту осуществления изобретения. Фиг. 14A - это блок-схема примера журнала 1250 регистрации подписок по фиг. 12B согласно одному варианту осуществления изобретения. Хотя фиг. 14A иллюстрирует эту структуру журнала регистрации как таблицу, следует понимать, что любая подходящая структура данных может использоваться (к примеру, хэш-таблица). Фиг. 14B - это блок-схема примерных производителей, иллюстрирующая безусловную зависимость производителя на основе поглощающей подписки согласно одному варианту осуществления изобретения. Фиг. 14C - это блок-схема примерных производителей, иллюстрирующая безусловную зависимость производителя на основе прикрепляющей подписки согласно одному варианту осуществления изобретения. Две строки показываются в таблице фиг. 14A заполненные содержимым, используемым в примерах фиг. 14B-C. Числа в кружках используются на фиг. 14B-C для того, чтобы иллюстрировать порядок, в котором операции выполняются согласно одному варианту осуществления изобретения.

На фиг. 14A, столбец 1400 ключа производителя подписчика, столбец 1405 типа подписки и столбец 1410 критериев подписки для триггерных производителей показаны так, чтобы, соответственно, сохранять содержимое, соответствующее имени столбца. Помимо этого, фиг. 14A показывает столбец 1425 режимов родительских связей, чтобы сохранять режим связывания для родительского производителя подписной зависимости; эта информация подробнее описана относительно фиг. 14B-C.

Фиг. 14A также показывает столбец 1415 согласования производителей и столбец 1420 завершения, используемые для поглощающих подписок. Столбец 1415 согласования производителей используется для того, чтобы сохранять ключи производителя для триггерных производителей, которые удовлетворяют критериям поглощающей подписки, тогда как столбец 1420 завершения используется для того, чтобы отслеживать, завершена ли поглощающая подписка в ходе данного выполнения текущего набора графов производителей. Столбец 1415 согласования производителей и столбец 1420 завершения предоставляют дополнительную необязательную оптимизацию, которая предоставляет возможность разделения работы по сканированию производителей, экземпляры которых созданы, между автоматическим формированием графа производителей и выполнением графа производителей, как описано далее в данном документе.

Фиг. 14A также показывает столбец 1430 родительских классов, столбец 1435 родительских методов и столбец 1437 родительских экземпляров, используемые для прикрепляющих подписок. Столбец 1430 родительских классов, столбец 1435 родительских методов и столбец 1437 родительских экземпляров, соответственно, сохраняют ключ класса, ключ метода и ключ экземпляра родительского производителя, который должен быть создан для прикрепляющей подписки. Помимо этого, фиг. 14A показывает столбец 1421 ссылок на производителей определения зависимостей, сохраняющий ссылку на производителя определения зависимостей, который создает подписку.

Поглощающая подписка

В зависимости производителя на основе поглощающей подписки, зависимость идет для совокупности всех производителей текущей структуры графа производителей, которые отвечают критериям поглощающей подписки. Со ссылкой на фиг. 14B, 1 в кружке указывает, что создается экземпляр производителя 1450 (к примеру, в результате обозначения производителя 1450 как интересующего производителя, в результате автоматического обнаружения производителя 1450 как потомства интересующего производителя и т.д.). Производитель 1450 основан на методе, для которого объявление зависимостей производителя включает зависимость производителя (к примеру, с идентификатором аргумента X). 2 в кружке указывает, что зависимость производителя для производителя 1450 обрабатывается так, чтобы идентифицировать производителя 1455.

3 в кружке указывает то, что производитель 1450 связывается (в вышеупомянутом примере, через идентификатор аргумента X) на графе производителей с производителем 1455 как дочерний производитель. 4 в кружке указывает выполнение производителя 1455. Производитель 1455 - это производитель определения зависимостей, который включает в себя код объявления зависимостей производителя, указывающий зависимость производителя на основе поглощающей подписки и указывающий критерии поглощающей подписки. По сути, выполнение производителя 1455 приводит к заполнению журнала регистрации подписок. Относительно примера в первой строке фиг. 14A, столбец 1400 ключа производителя подписчика, столбец 1405 типа подписки, столбец 1410 критериев подписки для триггерных производителей, столбец 1425 режимов родительских связей и столбец 1421 ссылок на производителя определения зависимостей, соответственно, заполняются ключом производителя для производителя 1450, индикатором того, что подписка имеет поглощающий тип, критериями поглощающей подписки, содержащимися в производителе 1455, и режимом связывания производителя 1450, связанным с производителем 1455 (которым, в случае поглощающей подписки, является зависимость аргументов и который включает в себя идентификатор аргумента, но индикатор прикрепления которого должен указывать не прикрепление - в вышеупомянутом примере, идентификатор аргумента X), и ссылкой на производителя 1455 (производитель определения зависимостей, который создает подписку).

5A-N в кружках указывают создание экземпляров производителей 1460A-N. В этом примере, производители 1460A-N удовлетворяют критериям поглощающей подписки и, таким образом, являются триггерными производителями. По сути, 6A-N в кружках указывает связывание производителя 1450 с производителями 1460A-N (в вышеупомянутом примере, через идентификатор аргумента X). 7 в кружке указывает то, что зависимость поглощающей подписки завершена для текущего выполнения графа(ов) производителей, и производитель 1450 затем выполняется.

В одном варианте осуществления изобретения, критериями поглощающей подписки могут быть один или более из любых из ключей, составляющих ключ производителя. Таким образом, в вариантах осуществления изобретения, где ключ производителя содержит ключ класса, ключ экземпляра и ключ метода, критериями подписки могут быть один или более таких ключей. В качестве примера со ссылкой на фиг. 11C, сканирование производителей, экземпляры которых созданы, на предмет тех, которые удовлетворяют критериям подписки, является сканированием через один или более из первых трех столбцов структуры графа(ов) производителей, чтобы определять, соответствуют ли ключи производителей, экземпляры которых созданы, ключам критериев поглощающей подписки. Хотя, в одном варианте осуществления изобретения, критериями поглощающей подписки могут быть один или более из любых из ключей, составляющих ключ производителя, в альтернативных вариантах осуществления изобретения, критерии поглощающей подписки ограничены поднабором ключей, составляющих ключ производителя.

Прикрепляющая подписка

В зависимости производителя на основе прикрепляющей подписки, зависимость инструктирует создание экземпляра родительского производителя для каждого производителя, который удовлетворяет критериям прикрепляющей подписки. Со ссылкой на фиг. 14C, 1 в кружке указывает, что создается экземпляр производителя 1470 (к примеру, в результате обозначения производителя 1470 как интересующего производителя, в результате автоматического обнаружения производителя 1470 как потомства интересующего производителя через зависимость упорядочения (к примеру, в результате SequencingDependency или WeaklyConstrainedDependency и т.д.). Производитель 1470 - это производитель определения зависимостей, который включает в себя код объявления зависимостей производителя, указывающий прикрепляющую подписку, критерии прикрепляющей подписки для триггерных производителей и характеристики прикрепляющей подписки для родительского производителя, который должен быть создан.

Выполнение производителя 1470 приводит к заполнению журнала регистрации подписок. Относительно примера во второй строке фиг. 14A, столбец 1400 ключа производителя подписчика, столбец 1405 типа подписки и столбец 1410 критериев подписки для триггерных производителей, соответственно, заполняются ключом производителя для производителя 1470, индикатором того, что подписка имеет прикрепляющий тип, и критериями прикрепляющей подписки для триггерных производителей, содержавшихся в производителе 1470. Помимо этого, столбец 1430 родительских классов, столбец 1435 родительских методов, столбец 1437 родительских экземпляров и столбец 1425 режимов связывания родительского производителя, который должен быть связан с триггерным производителем, заполняется характеристиками прикрепляющей подписки для родительского производителя, который должен быть создан, - в этом варианте осуществления изобретения, соответственно, классом родительского производителя, экземпляр которого должен быть создан, методом родительского производителя, экземпляр которого должен быть создан, экземпляром родительского производителя, который должен быть создан (если оставлено пустым, должно быть равно ключу экземпляра триггерного производителя), режимом связывания, которым, в случае прикрепляющей подписки, может быть: 1) зависимость аргументов, полей или упорядочения; 2) идентификатор аргумента, если зависимость аргументов - идентификатор аргумента родительского производителя, который должен быть связан с триггерным производителем (к примеру, идентификатор аргумента Y). Помимо этого, столбец 1421 ссылок на производителей определения зависимостей заполняется ссылкой на производителя определения зависимостей, который создал подписку (на фиг. 14C, производитель 1470).

Со ссылкой на фиг. 14C, 2 в кружке указывает, что создается экземпляр производителя 1475 (к примеру, в результате обозначения производителя 1475 как интересующего производителя, в результате автоматического обнаружения производителя 1475 как потомства интересующего производителя и т.д.). Помимо этого, определяется то, удовлетворяет ли производитель 1475 критериям прикрепляющей подписки для триггерного производителя. 3 в кружке указывает то, что в ответ на триггерный производитель 1475 создается экземпляр производителя 1480 на основе характеристик прикрепляющей подписки для родительского производителя, который должен быть создан. В отношении примерной второй строки фиг. 14C, к ключу класса, ключу метода, ключу экземпляра и режиму связывания осуществляется доступ из столбца 1430 родительских классов, столбца 1435 родительских методов, столбца 1437 экземпляров и столбца 1425 режимов родительских связей, соответственно. Родительский производитель имеет ключ производителя, содержащий ключ класса, к которому осуществляется доступ, ключ экземпляра, к которому осуществляется доступ (если оставлено пустым, ключ экземпляра триггерного производителя (на фиг. 14C, производителя 1475)), и ключ метода, к которому осуществляется доступ, - в примере по фиг. 14C - это производитель 1480. 4 в кружке указывает то, что родительский производитель 1480, экземпляр которого создан, связывается на графе производителей с дочерним триггерным производителем 1475 через режим связывания, к которому осуществляется доступ (в вышеупомянутом примере, тип режима связывания = зависимость аргументов; идентификатор аргумента режима связывания = Y). Также 4 в кружке, в случае зависимости аргументов, индикатор прикрепления задается так, чтобы указывать прикрепление - что зависимость производителя в этой позиции оператора объявления зависимостей производителя для метода, на котором родительский производитель 1480, экземпляр которого создан, основан, должна быть проигнорирована для производителя 1480 - это предотвращает перезапись связи, созданной посредством зависимости производителя на основе прикрепляющей подписки, посредством последующих операций автоматического формирования графа производителей.

В одном варианте осуществления изобретения, критериями поглощающей подписки для триггерных производителей могут быть один или более из ключей, составляющих ключ производителя. Таким образом, в вариантах осуществления, где ключ производителя содержит ключ класса, ключ экземпляра и ключ метода, критериями прикрепляющей подписки для триггера могут быть один или более из ключей классов, экземпляров и методов. В качестве примера со ссылкой на фиг. 11C, сканирование через производителей, экземпляры которых созданы, на предмет тех, которые отвечают критериям прикрепляющей подписки для триггерных производителей, является сканированием через один или более из первого-третьего столбцов структуры графа(ов) производителей, чтобы определять то, соответствуют ли ключи производителей, экземпляры которых созданы, ключам критериев прикрепляющей подписки для триггерных производителей. Хотя в одном варианте осуществления изобретения, критериями прикрепляющей подписки для триггерных производителей могут быть один или более из ключей, составляющих ключ производителя, в альтернативных вариантах осуществления изобретения, критериями поглощающей подписки могут быть более ограниченное число ключей, составляющих ключ производителя.

Фиг. 14D-E иллюстрируют выбор родительского производителя на основе родительского производителя определения зависимостей согласно одному варианту осуществления изобретения. Хотя фиг. 14D-E описываются в отношении зависимостей аргументов, варианты осуществления изобретения могут поддерживать использование зависимостей упорядочения и полей.

Фиг. 14D иллюстрирует выбор родительского производителя на основе родительского производителя определения зависимостей, созданного посредством прикрепляющей подписки, согласно одному варианту осуществления изобретения. Аналогично фиг. 14C фиг. 14D показывает производитель 1470 прикрепляющей подписки и триггерный производитель 1475; тем не менее, вместо производителя 1480 фиг. 14D показывает производитель 1480 определения зависимостей, созданный через прикрепляющую подписку производителя 1470 прикрепляющей подписки. Дополнительно, фиг. 14D показывает то, что режимом связывания прикрепляющей подписки является зависимость аргументов, идентификатор аргумента = X, и индикатор прикрепления = прикрепление. Как проиллюстрировано посредством пунктирной кривой линии от производителя 1475 к производителю 1480 определения зависимостей, DEP, возвращаемый посредством производителя определения зависимостей, может быть основан на выводе самого производителя на 1475 (аргумент идентификатора аргумента = X). На фиг. 14D, производитель 1480 определения зависимостей возвращает неподписную восходяще объявляемую зависимость производителя для производителя 1482, причем режим связывания указывает зависимость аргументов и идентификатор аргумента = Y. Хотя идентификаторы аргументов X и Y используются на фиг. 14D, чтобы показать то, что они могут отличаться, следует понимать, что они могут быть равными.

Фиг. 14E иллюстрирует выбор родительского производителя на основе родительского производителя определения зависимостей, созданного посредством дочернего производителя определения зависимостей, причем этот дочерний производитель определения зависимостей связывается посредством зависимости упорядочения, согласно одному варианту осуществления изобретения; Фиг. 14E аналогична по структуре фиг. 14D; в частности, производители 1475, 1480 и 1482 заменены на производителей 1486, 1496 и 1498. Тем не менее, вместо создания посредством производителя 1470 прикрепляющей подписки связи между производителями 1480 и 1475, производитель 1486 имеет зависимость упорядочения производителя 1494 определения зависимостей (к примеру, созданного через UpwardDependency или WeaklyConstrainedDependency), который создает производитель 1496 определения зависимостей через неподписную восходяще объявляемую зависимость.

Следует отметить, что зависимости на основе прикрепляющей подписки и неподписные восходяще объявляемые зависимости (к примеру, созданный через UpwardDependencies и/или WeaklyConstrainedDependencies) приводят к восходящему построению графа производителей (в противоположность нисходящему построению, описанному ранее в данном документе). Дополнительно, это восходящее построение не ограничено построением из одного уровня, а может быть из нескольких уровней (к примеру, если вследствие зависимости на основе прикрепляющей подписки или неподписной восходяще объявляемой зависимости создается экземпляр родительского производителя, то тот же родительский производитель также может быть триггерным производителем для прикрепляющей подписки или может включать в себя неподписную восходяще объявляемую зависимость и инструктировать создание экземпляра другого родительского производителя, и т.д.). В этом смысле, зависимости на основе прикрепляющей подписки, а также неподписные восходяще объявляемые зависимости изменяют построение графа производителей на противоположное.

Хотя, в некоторых вариантах осуществления изобретения, родительские производители, идентифицированные посредством характеристик прикрепляющей подписки, являются стандартными производителями (см. фиг. 14C), альтернативные варианты осуществления могут быть реализованы так, чтобы поддерживать идентификацию других типов производителей. Например, в вариантах осуществления изобретения, которые дают возможность характеристикам прикрепляющей подписки идентифицировать производителя определения зависимостей (см. фиг. 14D), такой производитель определения зависимостей может осуществлять доступ к выводу триггерного производителя и может на основе этого вывода запускать создание конкретного производителя как родительского производителя, который должен прикрепляться на дочернем элементе (этот родительский производитель может уже существовать или нет; если он уже существует, то он просто связывается, и дочерний производитель добавляется к его аргументу; если он еще не существует, то он создается). Случай, где производитель определения зависимостей возвращает постоянный производитель, моделирует поглощающую подписку. Случай, где производитель определения зависимостей возвращает производитель, ключ экземпляра которого является уникальным для каждого триггерного производителя (к примеру, возвращает производитель, ключ экземпляра которого - это ключ триггерного производителя), приводит к отдельному родительскому производителю на каждый дочерний производитель и упоминается как чистая прикрепляющая подписка. Случай, где производитель определения зависимостей возвращает ключ экземпляра, который не является ни постоянным, ни уникальным на каждый триггерный производитель, позволяет смешивать характеры изменения чистых прикрепляющих подписок и поглощающих подписок и упоминается как нечистая прикрепляющая подписка.

Примерные преимущества

Как ранее описано, в одном варианте осуществления изобретения, зависимости производителя объявляются для методов как способ указывать упорядочение вызова методов с использованием соответствующих экземпляров (где соответствующие экземпляры включают в себя экземпляры, чтобы использовать как аргументы, экземпляры, которые должны быть использованы посредством методов экземпляров, и экземпляры метаклассов, используемые посредством методов классов), не используя код упорядочения вызовов вручную; фактически, работа по формированию части или всего кода упорядочения вызовов заменяется на следующее: 1) работу, выполняемую прикладным программистом для того, чтобы писать объявления зависимостей производителя; и 2) работу, выполняемую посредством среды выполнения, чтобы обнаруживать и строить граф(ы) производителей и выполнять производителей этих графов производителей. Хотя объем работ для того, чтобы писать среду выполнения, является относительно большим, она должен быть написана только один раз, и далее она может использоваться для того, чтобы выполнять любые объектно-ориентированные приложения, написанные для среды выполнения; в отличие от этого, для типичного приложения объем работ для того, чтобы писать объявления зависимостей производителя, является относительно небольшим по сравнению с написанием кода упорядочения вызовов вручную.

Нединамические зависимости производителя предусматривают способ указывать безусловный код упорядочения вызова метода и таким образом исключать необходимость в написании безусловного кода упорядочения вызовов вручную. Условные зависимости производителя предусматривают способ указывать условную обработку и таким образом заменять необходимость в написании условного кода упорядочения вызовов вручную. Поддержка зависимостей производителя, которые предоставляют возможность возвращения совокупности производителей, предусматривает способ указывать заполнение совокупности до того, как она передается в качестве параметра, и таким образом исключать необходимость в написании множества вызовов в коде упорядочения вызовов вручную, для того чтобы заполнять совокупность до того, как она передается в качестве параметра. Поддержка подписок предоставляет окружение, в котором программист не должен писать конкретный код прослушивания для каждого типа объекта, который должен быть прослушан (к примеру, в электронной таблице графоориентированного программирования на основе производителей, поглощающая подписка может использоваться для того, чтобы вычислять среднее диапазона ячеек (причем каждая ячейка является производителем) посредством указания по критериям поглощающей подписки идентифицировать ячейки в рамках диапазона и пересчитывать среднее каждый раз, когда новый производитель добавляется в поглощающую подписку; в электронной таблице графоориентированного программирования на основе производителей прикрепляющая подписка может использоваться в качестве конвертера валют посредством указания по критериям прикрепляющей подписки идентифицировать ячейки, содержащие содержимое валют, и характеристики прикрепляющей подписки прикрепляющего производителя(ей), экземпляр которого должен быть создан, который выполняет конвертацию валюты (производители (содержащие конвертированные значения), созданные посредством прикрепляющих подписок, в таком случае должны быть доступными для отображения в других ячейках).

Работа

Команды создания экземпляра

Фиг. 15 - это блок-схема последовательности операций для создания новых экземпляров согласно одному варианту осуществления изобретения. Как ранее описано со ссылкой на фиг. 10, модуль 1095 создания классов по фиг. 10 может быть реализован как часть модуля 1098 создания экземпляров. Блок-схема последовательности операций по фиг. 15 предполагает такой вариант осуществления и выполняется посредством модуля 1098 создания экземпляров; часть блок-схемы последовательности операций по фиг. 15, представляющая модуль 1095 создания классов, показывается как пунктирный этап 1580, который включает в себя этапы 1540 и 1550.

В ответ на команду создания экземпляра (этап 1510), управление переходит к этапу 1520. На этапе 1520 определяется то, существует ли уже экземпляр. Если нет, управление переходит к этапу 1530, иначе, экземпляр не должен быть создан, и управление переходит к этапу 1570, на котором блок-схема последовательности операций способа завершается. В одном варианте осуществления, который поддерживает ключи экземпляров, этап 1520 выполняется посредством осуществления доступа к структуре 1065 отслеживания экземпляров по фиг. 10 на предмет ключа экземпляра (и ключа класса, если ключи экземпляров не должны быть уникальными для классов), предоставляемого как часть команды создания экземпляра.

На этапе 1530 определяется то, загружено ли уже определение класса экземпляра. Если нет, управление переходит к этапу 1540; иначе, управление переходит к этапу 1560. В одном варианте осуществления, который поддерживает ключи классов, этап 1540 выполняется посредством осуществления доступа к структуре 1092 отслеживания классов по фиг. 10 на предмет ключа класса, предоставляемого как часть команды создания экземпляра.

На этапе 1540, класс загружается, и управление переходит к этапу 1550. На этапе 1550 определение класса должно быть сохранено согласно ключу класса и проанализировано, включая все операторы объявления зависимостей производителя (сохраненные посредством ключа метода в классе - см. фиг. 11D). От этапа 1550 управление переходит к этапу 1560. Со ссылкой на фиг. 10, следующее выполняется на этапах 1540 и 1550: 1) класс должен быть загружен из определений классов, которые включают в себя бизнес-логику 1010, в классы 1054 (эта загрузка приводит к сохранению методов и объявлений зависимостей производителя класса в методе и объявлениях 1056 зависимостей производителя); 2) класс должен быть добавлен в структуру 1092 отслеживания классов; и 3) методы должны быть добавлены в структуру 1058 отслеживания методов. Дополнительно, выходные классы методов должны быть загружены.

На этапе 1560, экземпляр класса должен быть создан и сохранен согласно ключу экземпляра. Со ссылкой на фиг. 10, экземпляр должен быть создан в экземпляры 1052; и экземпляр должен быть добавлен в структуру 1065 отслеживания экземпляров. От этапа 1550 управление переходит к этапу 1570, на котором блок-схема последовательности операций способа завершается. В некоторых вариантах осуществления изобретения, в которых используется методика объектно-реляционного преобразования, данные могут быть загружены из внешнего источника данных, чтобы заполнять поле экземпляра как часть этапа 1560.

В некоторых вариантах осуществления изобретения, классы и экземпляры могут быть загружены/экземпляр может быть создан таким образом, о котором среда выполнения со средствами поддержки графоориентированного программирования на основе производителей не имеет сведений (к примеру, на фиг. 9A, если среда 915 выполнения загружает/создает экземпляр без знания средой 910 выполнения). В таких случаях, варианты осуществления изобретения, которые также поддерживают ключ экземпляра, являющийся экземпляром класса InstanceKey (который содержит два элемента: характер ключа экземпляра, указывающий то, является ключевой идентификатор ссылкой на экземпляр или другой объект (такой как строка), и ключевой идентификатор, который может быть ссылкой или на экземпляр, или на другой объект (такой как строка)), этапы 1520 и 1530 запрашивают, создан ли экземпляр/загружены ли экземпляр и класс таким образом, о котором среда выполнения со средствами поддержки графоориентированного программирования на основе производителей знает. В случаях, если среда выполнения со средствами поддержки графоориентированного программирования на основе производителей не знает об уже загруженном классе, класс не должен быть загружен, но класс должен быть добавлен в структуру 1092 отслеживания классов, и методы должны быть добавлены в структуру 1058 отслеживания методов. В случаях, если среда выполнения со средствами поддержки графоориентированного программирования на основе производителей не знает об уже созданном экземпляре, экземпляр не должен быть создан, но экземпляр должен быть добавлен в структуру 1065 отслеживания экземпляров.

Команды создания производителя и отмены подмены

Фиг. 16 - это блок-схема последовательности операций для создания экземпляров новых производителей и отмены подмены производителей согласно одному варианту осуществления изобретения. Со ссылкой на фиг. 10, последовательности операций по фиг. 15 выполняются посредством модуля 1040 автоматического формирования графа производителей и модуля 1045 вывода подмененных производителей (или, как описано в отношении альтернативных вариантов осуществления со ссылкой на фиг. 10, модуля, который обрабатывает подмены и отмены подмены).

В ответ на команду создания производителя (этап 1600), управление переходит к этапу 1605. В одном варианте осуществления изобретения, команда создания производителя может выполняться в ответ на множество ситуаций. Таблица 2 ниже идентифицирует различные ситуации и передаваемые параметры согласно одному варианту осуществления изобретения.

Таблица 2 Ситуации Вызыва-ющий произво-дитель Вызываемый производитель (который должен быть создан, если еще не существует) Тип вызова Режим связывания Ссылка на производитель определения зависимостей Интересующий производитель Нет данных Интересующий производитель, который должен быть создан Интересующий Нет данных Нет данных Неподписной нисходяще объявляемый Роди-тельский элемент Дочерний элемент Неподписной нисходяще объявляемый Режим связывания вызывающих родительских производителей Производитель определения зависимостей, предоставляющий зависимость Прикрепляющая подписка Дочерний элемент Родительский элемент (родительский класс, метод и ключ экземпляра из характеристик прикрепляющей подписки для родительского производителя, который должен быть создан; если ключ экземпляра является пустым, ключ экземпляра существующего вызывающего дочернего производителя) Прикрепляющий Режим связывания вызываемых родительских производителей из характеристик прикрепляющей подписки для родительского производителя, который должен быть создан Производитель определения зависимостей, предоставляющий зависимость Подмена Нет данных Производитель, который должен быть подменен Подмененный Нет данных Нет данных Неподписной восходяще объявляемый Дочерний элемент Родительский элемент Неподписной восходяще объявляемый Режим связывания вызываемых родительских производителей Производитель определения зависимостей, предоставляющий зависимость

На этапе 1605 определяется то, существует ли уже производитель. Если нет, управление переходит к этапу 1610; иначе, управление переходит к этапу 1670. Этап 1605 выполняется посредством осуществления доступа к идентифицированному классу, экземпляру и методу (к примеру, посредством ключа и/или ссылки) как часть команды создания производителя. В одном варианте осуществления, который поддерживает ключи производителя, этап 1605 выполняется посредством осуществления доступа к структуре 1060 графа(ов) производителей по фиг. 10 для ключа производителя, предоставляемого как часть команды создания производителя (ключа производителя в столбце вызываемых производителей таблицы 2).

На этапе 1610 модуль создания экземпляров вызывается с помощью команды создания экземпляра, и управление переходит к этапу 1615. В одном варианте осуществления изобретения, этап 1610 выполняется посредством вызова блок-схемы последовательности операций фиг. 15 с использованием ключа экземпляра из ключа производителя в столбце вызываемых производителей таблицы 2.

На этапе 1615, к определению класса экземпляра производителя осуществляется доступ, и управление переходит к этапу 1620. Со ссылкой на фиг. 10, этап 1615 выполняется посредством использования ключа класса из ключа производителя в столбце вызываемых производителей таблицы 2, чтобы осуществлять доступ к соответствующему одному из классов 1054 согласно структуре 1092 отслеживания классов.

На этапе 1620, к методу и оператору объявления зависимостей производителя осуществляется доступ, и управление переходит к этапу 1625. Со ссылкой на фиг. 10, этап 1620 выполняется посредством использования ключа метода из ключа производителя в столбце вызываемых производителей таблицы 2, чтобы осуществлять доступ к соответствующему одному из методов и объявлений 1056 зависимостей производителя из класса, найденного на этапе 1615.

На этапе 1625, производитель добавляется на граф производителей, и управление переходит к этапу 1630. В отношении варианта осуществления изобретения на фиг. 11C, заполняются первые три столбца.

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

На этапе 1635, производитель связывается на графе(ах) производителей, если вызван благодаря зависимости. От этапа 1635 управление переходит к этапу 1640. Способ выполнения этапа 1635 зависит от ситуации, которая привела к выполнению команды создания производителя (см. фиг. 20). Например, если ситуация заключается в том, что это интересующий производитель или подменяемый производитель, то он не вызван благодаря зависимости, и ничего не предпринимается. Напротив, если ситуация - это неподписной нисходяще объявляемый элемент, то он вызван вследствие неподписной нисходяще объявляемой зависимости; и в отношении варианта осуществления изобретения на фиг. 11C выполняется следующее: 1) связь(и) родительского производителя(ей) в столбце 1150 вызываемого дочернего производителя (столбец вызываемых производителей таблицы 2) модифицируется с помощью ссылки на родительский производитель на строку родительского вызывающего производителя (столбец вызывающих производителей таблицы 2) и ссылки на производитель определения зависимостей (столбец ссылок на производители определения зависимостей таблицы 2); и 2) столбец 1160 связи(ей) дочернего производителя(ей) строки родительского вызывающего производителя (столбец вызывающих производителей таблицы 2) модифицируется с помощью ссылки на дочерний производитель на строку вызываемого дочернего производителя (столбец вызываемых производителей таблицы 2), ссылки на производитель определения зависимостей (столбец ссылок на производители определения зависимостей таблицы 2) и режима связывания (заданного согласно столбцу режимов связывания таблицы 2).

Напротив, если ситуация - это прикрепляющая подписка, то он вызван благодаря идентификации триггерного производителя; и в отношении варианта осуществления изобретения на фиг. 11C, выполняется следующее: 1) столбец 1150 связи(ей) родительского производителя(ей) вызывающего дочернего производителя (столбец вызывающих производителей таблицы 2) модифицируется с помощью ссылки родительского производителя на строку родительского вызываемого производителя (столбец вызываемых производителей таблицы 2) и ссылки на производителя определения зависимостей (столбец ссылок на производителей определения зависимостей таблицы 2); и 2) связь(и) 1160 дочернего производителя(ей) строки родительского вызываемого производителя (столбец вызываемых производителей таблицы 2) модифицируется с помощью ссылки дочернего производителя на строку вызывающего дочернего производителя (столбец вызывающих производителей таблицы 2), ссылки на производитель определения зависимостей (столбец ссылок на производителей определения зависимостей таблицы 2), режима связывания (заданного согласно столбцу режимов связывания таблицы 2) и индикатора прикрепления, заданного так, чтобы указывать прикрепление. В этом отношении, ситуация неподписного восходяще объявляемого элемента обрабатывается способом, аналогичным прикрепляющей подписке.

На этапе 1640, производитель помечается как невыполненный, и управление переходит к этапу 1645. В отношении варианта осуществления изобретения на фиг. 11C, столбец 1180 маркировок инкрементного выполнения соответствующей строки заполняется индикатором невыполнения.

На этапе 1645, определяется то, имеет ли производитель какие-либо зависимости и является неподмененным. Если да, управление переходит к этапу 1650; иначе, управление переходит к этапу 1665. Этап 1645 выполняется посредством проверки объявления зависимостей производителя, к которому осуществлен доступ на этапе 1620, и столбца типов вызовов таблицы 2.

На этапе 1650, для каждой зависимости в объявлении зависимостей производителя, которое должно быть теперь разрешено, число производителей определяется, и команда создания производителя активируется для каждого из них. От этапа 1650, управление переходит к этапу 1655. Различные варианты осуществления изобретения определяют различные типы зависимости в разное время; способ выполнения этапа 1650 в одном примерном варианте осуществления изобретения описан далее в данном документе.

На этапе 1655, производитель добавляется в журнал регистрации начала выполнения, если все его зависимые производители существуют и выполнены. От этапа 1655 управление переходит к этапу 1660. Когда для данного производителя, экземпляр которого создан как часть текущей итерации этой последовательности операций, этап 1655 выполнен, то вызов другой итерации этой последовательности операций для производителя, от которого зависит данный производитель, должен возвращать состояние выполнения этого производителя (см. этап 1660) (к примеру, относительно варианта осуществления изобретения на фиг. 11C, состояние из столбца 1180 маркировок инкрементного выполнения соответствующих строк). Если все зависимые производители существуют и состоянием выполнения всех зависимых производителей является "выполняется", то производитель текущей итерации добавляется в журнал регистрации начала выполнения.

На этапе 1660, состояние выполнения производителя возвращается как параметр.

На этапе 1670, аналогичному этапу 1635, производитель связывается на графе(ах) производителей, если вызван благодаря зависимости. От этапа 1670, управление переходит к этапу 1675. Этап 1670 может быть достигнут по множеству причин. Например, этап 1670 может быть достигнут, поскольку ранее создан экземпляр производителя в ответ на команду подмены производителя, но он не связан на графе производителей. В качестве еще одного примера, этап 1670 может быть достигнут, поскольку производитель уже является частью графа производителей и добавляется на другой (к примеру, ранее создан его экземпляр в ответ на то, что является интересующим производителем, потомством интересующего производителя и т.д.).

На этапе 1675, определяется то, что последовательность выполнения для нового производителя вызвана вследствие подмены, зависимости на основе прикрепляющей подписки или неподписной восходяще объявляемой зависимости. Если да, управление переходит к этапу 1680; иначе, управление переходит к этапу 1660. Этап 1675 выполняется посредством проверки столбца типов вызовов таблицы 2, чтобы удостовериться, является ли он вызовом подмененного производителя, зависимости на основе прикрепляющей подписки или неподписной восходяще объявляемой зависимости.

На этапе 1680, аналогично этапу 1640, производитель помечается как невыполненный, и управление переходит к этапу 1665. Этап 1680 может быть достигнут по множеству причин.

На этапе 1665, производитель добавляется в журнал регистрации начала выполнения, если еще не присутствует, и управление переходит к этапу 1660.

В ответ на команду отмены подмены производителя (этап 1690), управление переходит к этапу 1695. На этапе 1695, производитель помечается как неподмененный, и управление переходит к этапу 1640. В отношении варианта осуществления изобретения фиг. 11C, к кэшированию выводов производителя и столбцу 1170 индикаторов вывода подмененных производителей строки производителя осуществляется доступ, и они изменяются так, чтобы указывать то, что производитель больше не является подмененным. Продолжая эту последовательность операций, этап 1640 должен приводить к этапу 1645, и если производитель имеет какие-нибудь зависимости - к этапу 1650, который должен инструктировать обнаружение и построение графа производителей под производителем, если это уже не сделано. Если граф производителей под производителем уже обнаружен и построен, то вызов команды создания производителя должен приводить к переходу последовательности операций от 1600 к 1605, к 1670 и т.д.; дополнительно, возврат состояния выполнения производителей графа под производителем на этапе 1660 должен определять, добавлен ли производитель в журнал регистрации начала выполнения на этапе 1655. Тем не менее, если граф производителей под производителем не обнаружен и построен, то вызов команды создания производителя должен приводить его к обнаружению и сборке с переходом последовательности операций от 1600 к 1605, к 1610 и т.д.

Фиг. 17 - это блок-схема последовательности операций для этапа 1650 по фиг. 16 согласно одному варианту осуществления изобретения. Таким образом, управление переходит от этапа 1645 к этапу 1700 на этапе 1650. На этапе 1700, для каждой зависимости в объявлении зависимостей производителя (по одной для каждого из ArgumentDependency, FieldDependency, SequencingDependency, UpwardDependency и WeaklyConstrainedDependency) выполняются следующие этапы 1705-1745. В отношении фиг. 10 и 11D, к структуре отслеживания методов осуществляется доступ, чтобы определять информацию, касающуюся зависимости производителя. Также следует понимать, что этапы 1715, 1725, 1730, 1740, 1745 и 1750 являются оптимизацией, когда выполняются до выполнения графа производителей.

На этапе 1705, определяется то, является ли зависимость зависимостью аргументов, уже связанной вследствие прикрепляющей зависимости. Если да, управление переходит к этапу 1710, где последовательность операций завершается для этой зависимости; иначе, управление переходит к этапу 1715. Относительно варианта осуществления изобретения, показанного на фиг. 11C, индикатор проверяет прикрепления, чтобы определять то, подчиняется идентификатор аргумента этой зависимости аргументов на основе прикрепляющей подписки или восходяще объявляемой зависимости аргументов.

На этапе 1715, определяется то, является ли зависимость условной зависимостью. Если да, управление переходит к этапу 1720; иначе, управление переходит к этапу 1725. Этап 1715 выполняется посредством проверки объявления зависимостей производителя для дочернего производителя, идентифицированного посредством зависимости, чтобы определять, является ли оно пустой (дочерний производитель является и независимым производителем). Относительно фиг. 13A-J, это является истиной для производителей с числами в пунктирном кружке (к примеру, на фиг. 13D, производителя CU::IV::DELTA), но не является истиной для других производителей (к примеру, на фиг. 13D, производителя CW::IY::BETA). Таким образом, со ссылкой на фиг. 13D, этап 1715 представляется посредством 1, 4 и 8 в кружке. Этап 1715 и последовательность операций от него посредством этапов 1725-1750 являются оптимизацией как в том, что исключают добавление/связывание производителей с числами в пунктирном кружке на графе производителей, так и в том, что делят работу выполнения производителей между автоматическим формированием графа производителей и выполнением графа производителей.

На этапе 1720, команда создания производителя для производителя определения зависимостей активируется, и последовательность операций завершается. Например, со ссылкой на фиг. 13D, этап 1720 инструктирует то, что представляется посредством 5, 6 и 7 в кружке.

На этапе 1725, производитель определения зависимостей выполняется, и управление переходит к этапу 1730. Например, со ссылкой на фиг. 13D, этап 1725 представляется посредством 11 в кружке (таким образом, поток последовательности операций по фиг. 17 иллюстрирует ранее описанный вариант осуществления, в котором 9 и 10 в кружке по фиг. 13D не выполняются).

На этапе 1730, определяется то, является ли зависимость неподписной зависимостью. Если да, управление переходит к этапу 1750; иначе управление переходит к этапу 1740. Другими словами, на этапе 1725, код определения зависимости производителя в методе производителя определения зависимостей, который является частью объявления зависимостей производителя для родительского производителя, выполняется. После выполнения этого кода объявления зависимостей производителя, причем данный код должен идентифицировать то, является ли эта зависимость подписной зависимостью, тип зависимости производителя для родительского производителя определяется. Относительно примера на фиг. 13D, 11 в кружке должно приводить к переходу последовательности операций по фиг. 17 от этапа 1730 к этапу 1750.

На этапе 1750, число производителей, возвращенных посредством выполнения производителя определения зависимостей на этапе 1725, определяется, и команда создания производителя активируется для каждого из них с помощью аргументов, описанных в таблице 2, включая ссылку на производителя определения зависимостей, выполняемую на 1725. Например, со ссылкой на фиг. 13D, этап 1750 должен приводить к 12 и 13 в кружке и C и D в кружке.

В отношении примера поглощающей подписки по фиг. 14B, этап 1725 представляет 4 в кружке, что инструктирует прохождение потока через этап 1730 к этапу 1740.

На этапе 1740, подписка добавляется в журнал регистрации подписок, и если подписка является поглощающей, она помечается как незавершенная. От этапа 1740 управление переходит к этапу 1745. В отношении варианта осуществления изобретения, показанного на фиг. 14A, журнал регистрации подписок заполняется подпиской так, как ранее описано.

На этапе 1745, все производители, экземпляр которых создан, сканируются на предмет того, чтобы удостоверяться, соответствуют ли они критериям подписки (и таким образом являются триггерными производителями), и все соответствия обрабатываются.

Фиг. 18 - это блок-схема последовательности операций для этапа 1745 по фиг. 17 согласно одному варианту осуществления изобретения; таким образом, управление переходит от этапа 1740 к этапу 1800 на этапе 1745. На этапе 1800, для каждого производителя, экземпляр которого создан, выполняются следующие этапы 1810-1830.

На этапе 1810 определяется то, удовлетворяет ли производитель критериям подписки. Если да, управление переходит к этапу 1815; иначе управление переходит к этапу 1830, где последовательность операций заканчивается для производителя, в настоящий момент обрабатываемого. В отношении вариантов осуществления изобретения, показанных на фиг. 11C и 14A, к графу(ам) производителей осуществляется доступ, чтобы определять то, включают ли они в себя производителей, которые удовлетворяют критериям подписки.

Способ обработки совпадающего производителя зависит от типа обрабатываемой подписки. В отношении этапа 1815, если подписка имеет поглощающий тип, управление переходит к этапу 1825; иначе управление переходит к этапу 1820. Этап 1815 должен выполняться в ответ на тип подписки, добавленный на этапе 1740 или 2235.

На этапе 1825, совпадающий производитель добавляется в журнал регистрации подписок, и производитель с поглощающей подпиской связывается с совпадающим производителем. От этапа 1825, управление переходит к этапу 1830. В отношении вариантов осуществления изобретения, показанных на фиг. 11C и 14A-B, выполняется следующее: 1) критерии подписки из критериев подписки для столбца 1410 триггерных производителей использованы на этапе 1810, и совпадающий производитель найден (к примеру, один из производителей 1460A-N); 2) совпадающий производитель добавляется в столбец 1415 совпадающих производителей в строке подписки; и 3) производитель с поглощающей подпиской (к примеру, производитель 1450) связывается с совпадающим производителем (к примеру, одним из производителей 1460A-N) в структуре графа(ов) производителей по фиг. 11C (с помощью ссылки на производитель определения зависимостей, извлеченной из столбца 1421 ссылок на производителей определения зависимостей журнала 14A регистрации подписок для данной поглощающей подписки).

На этапе 1820, команда создания производителя активируется для родительского производителя, который должен быть создан. От этапа 1820 управление переходит к этапу 1830, где блок-схема последовательности операций завершается для текущего производителя, выбранного на этапе 1800. В отношении вариантов осуществления изобретения, показанных на фиг. 14A и 14C, выполняется следующее: 1) критерии подписки из критериев подписки для столбца 1410 триггерных производителей используются на этапе 1810, и совпадающий производитель найден (к примеру, производитель 1475); и 2) команда создания производителя активируется с параметрами таблицы 2, заданными следующим образом: a) тип вызова - это прикрепляющая подписка; b), вызывающий производитель - это ключ производителя для вызывающего дочернего производителя (к примеру, производителя 1475); c) вызываемый производитель - это ключ производителя для вызываемого родительского производителя, который должен быть создан (к примеру, производителя 1480), причем этот ключ производителя формируется с помощью ключа родительского класса, экземпляра и метода из характеристик прикрепляющей подписки для родительского производителя, который должен быть создан (фиг. 14A, столбцы 1430, 1435 и 1437) (если ключ экземпляра является пустым, ключ экземпляра вызывающего дочернего производителя используется); d) режим связывания для вызываемого родительского производителя (фиг. 14A, столбец 1425 режимов связывания); и e) ссылка на производитель определения зависимостей, извлеченная из столбца 1421 ссылок на производителей определения зависимостей журнала 14A регистрации подписок для данной прикрепляющей подписки.

Фиг. 19 - это блок-схема последовательности операций для этапа 1630 по фиг. 16 согласно одному варианту осуществления изобретения. Таким образом, управление переходит от этапа 1625 к этапу 1900 на этапе 1630. Фиг. 19 во многом аналогична фиг. 18. В частности, этапы 1910, 1915, 1920 и 1930 по фиг. 19 идентичны этапам 1810, 1815, 1820 и 1830; тогда как этапы 1900 и 1925 отличаются от этапов 1800 и 1825. По сути, только различие описано здесь.

Этап 1900 указывает, что последовательность операций выполняется для каждой зарегистрированной подписки, тогда как этап 1800 указывает, что последовательность операций выполняется для каждого производителя, экземпляр которого создан. Таким образом, если последовательность операций по фиг. 18 ориентирована на одну подписку и сканирование всех производителей, последовательность операций по фиг. 19 ориентирована на один производитель и сканирование всех подписок.

Этап 1925 является таким же, как этап 1825, за исключением того, что поглощающая подписка помечается как незавершенная. В отношении варианта осуществления изобретения, показанного на фиг. 14A, столбец 1420 завершения в соответствующей строке обновляется так, чтобы указывать незавершенную подписку.

Фиг. 20 - это блок-схема последовательности операций для этапов 1635 и 1670 по фиг. 16 согласно одному варианту осуществления изобретения. Таким образом, управление переходит от этапа 1605 и этап 1630 к этапу 2005 на этапах 1635 и 1670. На этапе 2005 определяется то, активирована ли эта итерация блок-схемы последовательности операций по фиг. 16 вследствие зависимости (к примеру, из этапа 1630 (этапа 1920) или 1650 (этапов 1720, 1750 или 1745/1820) предыдущей итерации). Если нет, управление переходит к этапу 1640 или 1675 в зависимости от того, выполнен вход в последовательность операций (из этапа 1630 или 1605).

На этапе 2010 определяется то, вызвана ли последовательность операций вследствие прикрепляющей подписки или неподписной восходяще объявляемой ситуации. Если нет, управление переходит к этапу 2015; иначе управление переходит к этапу 2020. Этап 2010 выполняется посредством проверки параметра типа вызова из таблицы 2 (т.е. является тип вызова прикрепляющей подпиской или неподписным восходяще объявляемым или нет). В отношении вариантов осуществления изобретения, показанных на фиг. 18 и 19, если команда создания производителя активирована из этапов 1820 или 1920.

На этапе 2020, текущий родительский производитель связывается с дочерним вызывающим производителем. В отношении вариантов осуществления изобретения, показанных на фиг. 11C и 14C, вызываемый родительский производитель (к примеру, производитель 1480), идентифицированный посредством параметра из столбца вызываемых производителей таблицы 2, связывается в структуре графа(ов) производителей по фиг. 11C с вызывающим дочерним производителем (к примеру, производитель 1475), идентифицированным посредством параметра из столбца вызывающих производителей таблицы 2, используя режим связывания и ссылку на производитель определения зависимостей, идентифицированную посредством параметра из режима связывания и столбцов ссылок на производителей определения зависимостей таблицы 2. Если родительский элемент существовал ранее, характер изменения этапа 2020 имитирует характер изменения зависимости на основе поглощающей подписки в том смысле, что один аргумент может преобразовываться к нулю или более дочерних производителей.

На этапе 2015, вызывающий родительский производитель связывается с текущим вызываемым дочерним производителем. В отношении варианта осуществления изобретения, показанного на фиг. 11C, вызывающий родительский производитель, идентифицированный посредством параметра из столбца вызывающих производителей таблицы 2, связывается в структуре графа(ов) производителей по фиг. 11C с вызываемым дочерним производителем, идентифицированным посредством параметра из столбца вызываемых производителей таблицы 2, с использованием ссылки на производитель определения зависимостей, идентифицированный посредством столбца ссылок на производителей определения зависимостей таблицы 2. От этапов 2015 и 2020 управление переходит к этапу 1640 или 1675 в зависимости от того, где выполнен вход в последовательность операций (из этапа 1605 или 1630).

Фиг. 21 - это блок-схема последовательности операций для подмены производителей согласно одному варианту осуществления изобретения. Со ссылкой на фиг. 10, последовательность операций по фиг. 21 выполняется посредством модуля 1045 подмены производителей (или, как описано в отношении альтернативных вариантов осуществления, касающихся фиг. 10, модуля, который обрабатывает подмены и отмены подмены).

В ответ на команду подмены производителя (этап 2110), управление переходит к этапу 2120. На этапе 2120, команда создания производителя активируется для производителя, идентифицированного посредством команды подмены производителя, и управление переходит к этапу 2130. Этап 2120 выполняется в одном варианте осуществления изобретения в случае, если экземпляр производителя, который должен быть подменен, еще не создан, а также так, чтобы помечать производителя как невыполненный (этап 1640 или 1680) и регистрировать его в журнале регистрации начала выполнения (этап 1665). Альтернативный вариант осуществления изобретения, который не разрешает подмену производителя, экземпляр которого еще не создан, должен выполнять дополнительную проверку между этапами 1605 и 1610, чтобы определять то, вызвана ли эта команда создания производителя в ответ на команду подмены производителя, и указывать ошибку, если эта команда создания производителя вызвана в ответ на команду подмены производителя.

На этапе 2130, вывод в кэше выводов производителя (и в экземпляре, если поле) задается, и производитель помечается как подмененный.

Команды глобального выполнения

Фиг. 22A - это часть блок-схемы последовательности операций для выполнения текущего графа(ов) производителей согласно одному варианту осуществления изобретения; тогда как фиг. 22B - это другая часть блок-схемы последовательности операций для выполнения текущего графа(ов) производителей согласно одному варианту осуществления изобретения. Со ссылкой на фиг. 10, последовательность операций по фиг. 22 выполняется посредством модуля 1070 выполнения графа производителей.

В ответ на команду глобального выполнения, этап 2200 показывает то, что набор вариантов производителей выбирается, чтобы выполняться, на основе производителей в журнале регистрации начала выполнения, и управление переходит к этапу 2205. В одном варианте осуществления изобретения, подмененные производители помечаются как невыполненные, и их выполнение возвращает подмененный результат (в противоположность инструктированию выполнения их метода), текущий набор вариантов производителей - это производители в журнале регистрации начала выполнения. Хотя выше описан один вариант осуществления изобретения, в котором подмененные производители помечаются как невыполненные, и их выполнение возвращает их подмененный результат (в противоположность инструктированию выполнения их метода), альтернативные варианты осуществления могут работать по-другому (к примеру, помечать подмененные производители как выполненные, и при выборе текущего набора вариантов производителей, независимые производители журнала регистрации начала выполнения и родительские элементы подмененных производителей в журнале регистрации начала выполнения выбираются).

На этапе 2205, поднабор производителей, готовых к выполнению, выбирается из набора вариантов производителей, и управление переходит к этапу 2210. Примерный способ выполнения этапа 2205 описан далее в данном документе.

На этапе 2210, производители из текущего набора готовых производителей сортируются по типу - стандартные производители переходят к этапу 2215, а производители определения зависимостей переходят к этапу 2225. В одном варианте осуществления изобретения, этап 2210 выполняется посредством проверки класса возврата производителя. В отношении фиг. 10 и 11D, к структуре отслеживания методов осуществляется доступ, чтобы определять, является ли выходной класс производителя DEP, и, таким образом, этот производитель является производителем определения зависимостей.

На этапе 2215, все стандартные производители в текущем наборе готовых производителей выполняются, и управление переходит к этапу 2220. В одном варианте осуществления изобретения, этап 2215 выполняется посредством вызова метода с любыми входными параметрами, преобразованными из выводов любых дочерних производителей, вытекающих из зависимостей аргументов (для аргументов, идентификатор аргумента режима связывания используется для того, чтобы преобразовывать вывод соответствующего дочернего производителя в соответствующий входной аргумент выполняемого метода). В некоторых вариантах осуществления изобретения, такое выполнение может приводить к выполнению кода в методе дочернего производителя, который записывает вывод в данный механизм (к примеру, задает глобальную переменную, задает поле в экземпляре, который не является выводом производителя, влияет на внешний источник данных и т.д.), или кода в методе родительского производителя, который считал этот вывод из данного механизма). На этапе 2220, для тех родительских элементов, если таковые имеются, которые имеют поглощающую подписку для любого из этих выполняемых стандартных производителей, подписка помечается как незавершенная. От этапа 2220 управление переходит к этапу 2245. Со ссылкой на фиг. 14A, соответствующая строка столбца 1420 завершения задается так, чтобы указывать "незавершенный".

На этапе 2225, все производители определения зависимостей в текущем наборе готовых производителей подготавливаются к выполнению, и управление переходит к этапу 2230. Примерный способ выполнения этапа 2225 описан далее в данном документе.

На этапе 2230, все производители определения зависимостей в текущем наборе готовых производителей выполняются, и управление переходит к этапу 2235. В одном варианте осуществления изобретения, этап 2230 выполняется аналогично этапу 2215.

На этапе 2235, команда создания производителя выполняется для всех обнаруженных производителей, и регистрация и обработка подписок выполняется для всех подписок. Часть команды создания производителя этапа 2235 выполняется способом, аналогичным этапу 1750, тогда как регистрация и обработка подписок выполняется способом, аналогичным этапам 1740 и 1745.

На этапе 2240, выполняется добавление в набор вариантов производителей, заново добавленных в журнал регистрации начала выполнения. От этапа 2240 управление переходит к этапу 2245. Этап 2240 выполняется способом, аналогичным этапу 2200, исключая только производителей, заново добавленных в журнал регистрации начала выполнения, поскольку результат этапа 2230 и 2235 добавляется в набор вариантов производителей.

На этапе 2245, производители, которые выполнены, помечаются как выполненные, кэширование выводов производителя (и кэширование экземпляров) обновляется по мере необходимости, все родительские производители для производителей, которые выполнены, добавляются в текущий набор вариантов производителей, и производители, которые выполнены, удаляются из текущего набора вариантов и готовых производителей. От этапа 2245 управление переходит к этапу 2250.

На этапе 2250, определяется то, является ли набор вариантов производителей пустым. Если нет, управление переходит обратно к этапу 2205; иначе управление переходит к этапу 2255.

На этапе 2255, определяется то, завершены ли все подписки. Если да, управление переходит к этапу 2265, где блок-схема последовательности операций заканчивается; иначе управление переходит к этапу 2260. В отношении варианта осуществления изобретения на фиг. 14A, столбец 1405 типов подписки и столбец 1420 завершения сканируются на предмет любых поглощающих подписок, которые не завершены.

На этапе 2260, незавершенные поглощающие подписки обрабатываются, и управление переходит обратно к этапу 2205. Примерный способ выполнения этапа 2260 описан далее в данном документе.

Фиг. 23 - это блок-схема последовательности операций для этапа 2205 по фиг. 22 согласно одному варианту осуществления изобретения. Таким образом, управление переходит от этапа 2200 к этапу 2305 на этапе 2205. На этапе 2305, для каждого производителя в наборе вариантов производителей выполняются следующие этапы 2310-2325.

На этапе 2310, определяется то, имеет ли производитель какую-либо зависимость на основе поглощающей подписки, которая является незавершенной. Если да, управление переходит к этапу 2325; иначе управление переходит к этапу 2315. В отношении варианта осуществления фиг. 14A, столбец 1400 ключей производителей и столбец 1405 типов подписки абонента сканируются на предмет соответствия с текущим выбранным производителем и типом поглощающей подписки; и если совпадение найдено, столбец 1420 завершения в соответствующей строке проверяется, чтобы определять состояние этой зависимости на основе поглощающей подписки.

На этапе 2315, определяется то, выполнены ли производители, от которых зависит текущий выбранный производитель. Если нет, управление переходит к этапу 2325; иначе, управление переходит к этапу 2320. Относительно варианта осуществления изобретения, показанного на фиг. 11C, столбец 1180 маркировок инкрементного выполнения для строк дочерних зависимостей проверяется, чтобы определять состояние выполнения дочерних элементов текущего выбранного производителя.

На этапе 2320, текущий выбранный вариант производителя добавляется в текущий набор готовых производителей, и управление переходит к этапу 2325.

На этапе 2325, последовательность операций завершается для текущего производителя, выбранного на этапе 2305.

Фиг. 24 - это блок-схема последовательности операций для этапа 2225 по фиг. 22 согласно одному варианту осуществления изобретения. Таким образом, управление переходит от этапа 2210 к этапу 2405 на этапе 2225. На этапе 2405, для каждого производителя определения зависимостей выполняются следующие этапы 2410-2430.

На этапе 2410, определяется тип всех предыдущих зависимостей, сформированных посредством текущего выбранного производителя определения зависимостей. Если тип зависимости является неподписным, то управление переходит к этапу 2420; если тип является поглощающей подпиской, то управление переходит к этапу 2415; тогда как, если тип является прикрепляющей подпиской, то управление переходит к этапу 2425. Этап 2410 определяется посредством проверки текущего вывода производителя, сохраненного в кэшировании выводов производителей. В отношении класса DEP, вывод должен указать неподписной элемент, поглощающую подписку и прикрепляющую подписку.

На обоих этапах 2415 и 2425, запись удаляется из журнала регистрации подписок. В отношении варианта осуществления изобретения, показанного на фиг. 14A-C, выполняется следующее: 1) для поглощающих подписок (этап 2415), производитель определения зависимостей (к примеру, производитель 1455) используется для того, чтобы определять его родительский производитель (к примеру, производитель 1450) на графе(ах) производителей, и затем выполняется поиск родительского производителя в журнале регистрации подписок, и его запись удаляется; и 2) для прикрепляющих подписок (этап 2425), выполняется поиск производителя определения зависимостей (к примеру, производителя 1470) в журнале регистрации подписок, и его запись удаляется. От этапа 2415 управление переходит к этапу 2420; от этапа 2425 управление переходит к этапу 2420.

На этапе 2420, связи, уже созданные посредством текущего выбранного производителя определения зависимостей, очищаются с графа(ов) производителей, и управление переходит к этапу 2430. В отношении варианта осуществления изобретения, показанного на фиг. 11C, выполняется следующее. Сначала определяется то, "прикрепился" ли производитель определения зависимостей к существующему производителю. Это выполняется посредством сканирования столбца связей дочернего производителя для производителя определения зависимостей на фиг. 11C и проверки, имеет ли одна из связей индикатор прикрепления, указывающий прикрепление.

Если производитель определения зависимостей не прикрепился к существующему производителю, то: 1) для производителя определения зависимостей, который сформировал неподписные нисходяще объявляемые зависимости (зависимости аргументов, полей или упорядочения), осуществляется доступ к родительскому элементу производителя определения зависимостей на графе производителей через столбец 1150 ссылки(ок) на родительского производителя в строке текущего выбранного производителя определения зависимостей, и в этой записи родительского производителя, осуществляется доступ к столбцу 1160 связи(ей) дочернего производителя(ей), чтобы соответствовать ссылке на производитель определения зависимостей, и все ссылки дочерних производителей, имеющие эту ссылку на производитель определения зависимостей, очищаются; 2) для производителя определения зависимостей, который сформировал неподписные восходяще объявляемые зависимости, осуществляется доступ к родительскому элементу производителя определения зависимостей на графе производителей через столбец 1150 связи(ей) родительского производителя в строке текущего выбранного производителя определения зависимостей, и в этой записи родительского производителя, осуществляет доступ к столбцу 1150 связи(ей) родительского производителя, чтобы соответствовать ссылке на производитель определения зависимостей, и все ссылки родительских производителей, имеющие эту ссылку на производитель определения зависимостей, очищаются; 3) для производителя определения зависимостей, который сформировал поглощающую подписку, тот же характер изменения, что и для неподписных нисходяще объявляемых зависимостей, выполняется; и 4) для производителя определения зависимостей, который сформировал прикрепляющую подписку, выполняется поиск ссылки на производитель определения зависимостей, извлеченной из столбца 1421 журнала 14A регистрации подписок до удаления подписки, в структуре графа(ов) производителей столбца 1150 связи(ей) родительского производителя, и все ссылки родительских производителей, имеющие эту ссылку на производитель определения зависимостей, очищаются.

Если производитель определения зависимостей прикрепился к существующему производителю как результат неподписной восходяще объявляемой зависимости или прикрепляющей подписки, то осуществляется доступ к дочернему производителю, к которому прикрепился производитель определения зависимостей (дочернему производителю в столбце 1160 с индикатором прикрепления, указывающим прикрепление), и в этой записи дочернего производителя, осуществляется доступ к столбцу 1150 связи(ей) родительского производителя, чтобы соответствовать ссылке на производитель определения зависимостей, и все ссылки родительских производителей, имеющие эту ссылку на производитель определения зависимостей, очищаются.

На этапе 2430, последовательность операций завершается для производителя определения зависимостей, выбранного на этапе 2405.

Фиг. 25 - это блок-схема последовательности операций для этапа 2260 по фиг. 22 согласно одному варианту осуществления изобретения. Таким образом, управление переходит от этапа 2255 к этапу 2505 на этапе 2260. На этапе 2505, для каждого производителя с зависимостью на основе поглощающей подписки, которая является незавершенной, выполняются следующие этапы 2510-2525.

На этапе 2510, определяется то, выполнены ли все совпадающие производители. Если да, управление переходит к этапу 2515; иначе, управление переходит к этапу 2525. В отношении вариантов осуществления по фиг. 11C и 14A, к столбцу 1415 совпадающих производителей в соответствующей строке осуществляется доступ, чтобы определять совпадающие производители, и столбец 1180 инкрементного выполнения в соответствующих строках проверяется для каждого из совпадающих производителей.

На этапе 2515, поглощающая подписка помечается как завершенная, и управление переходит к этапу 2520. В отношении вариантов осуществления по фиг. 14A, столбец 1420 завершения в соответствующей строке задается так, чтобы указывать "завершенный".

На этапе 2520, производитель, выбранный на этапе 2505, добавляется в текущий набор вариантов производителей, и управление переходит к этапу 2525. На этапе 2525, последовательность операций завершается для производителя, выбранного на этапе 2505.

Сценарии

В некоторых вариантах осуществления, сценарии предоставляют способ указывать заполнение совокупности результатами вызова множества раз одних методов одних экземпляров с различными параметрами; и таким образом исключают необходимость написания нескольких вызовов кода упорядочения вызовов вручную одних методов одних экземпляров с различными параметрами. В некоторых вариантах осуществления изобретения, которые поддерживают динамическую зависимость, два различных сценария приложения могут иметь структурно различные графы или подграфы производителей на графе производителей приложения, если различные экземпляры, различные методы и/или различные классы используются в сценариях. Например, примерная прикладная программа предоставляется с тем, чтобы вычислять вывод на основе математической модели, которая принимает в качестве ввода именованный вектор числовых значений. Чтобы оценивать воздействия использования различных именованных векторов, сценарии, использующие различные экземпляры вектора, могут быть созданы, где каждый экземпляр соответствует различному вектору. Альтернативно, примерная прикладная программа может использовать один экземпляр вектора, но различные математические модели, для того чтобы вычислять интересующий вывод. Чтобы оценивать воздействие приспособления первой математической модели в сравнении с приспособлением второй математической модели, первый сценарий и второй сценарий могут быть созданы. В первом сценарии, первый метод, представляющий первую модель, активируется. Во втором сценарии, второй метод, представляющий вторую модель, активируется. Кроме того, класс в первом сценарии может быть или не быть таким же, как класс во втором сценарии. Если первый и второй методы задаются так, чтобы находиться в одном классе, то класс остается одинаковым в первом и втором сценариях. Тем не менее, если первый метод задается так, чтобы быть в первом классе, а второй метод задается так, чтобы быть во втором классе, отличном от первого класса, то первый и второй сценарии имеют различные классы. Отметим, что первый метод в первом классе и второй метод во втором классе могут иметь или не иметь идентичные имена.

Фиг. 26 иллюстрирует альтернативный вариант осуществления изобретения, которое поддерживает сценарий. Аналогично одному варианту осуществления, показанному выше на фиг. 1A, объектно-ориентированный исходный код 100 включает в себя класс 102, который, в свою очередь, включает в себя метод 104 и объявление 106 зависимостей производителя для метода 104. Конечно, класс 102 должен типично включать в себя одно или более полей (не показаны) и дополнительных методов (не показаны). Помимо этого, объектно-ориентированный исходный код 100 типично должен включать в себя дополнительные классы.

Как описано выше относительно фиг. 1A, экземпляр 108 класса 102 создается во время выполнения. Экземпляр 108 включает в себя данные полей класса 102. Помимо этого, создается экземпляр производителя 110, причем производитель 110 идентифицирует класс 102, экземпляр 108 класса 102 (который ассоциативно связан с методом 104 класса 102) и метод 104 класса 102. Объявление 106 зависимостей производителя идентифицирует для среды выполнения набор из нуля или более производителей 112 (упоминаемых как дочерние производители для производителя 110), который должен быть выполнен перед выполнением производителя 110. Другими словами, производитель 110 зависит от набора из нуля или более производителей 112. В дополнение или вместо потребления выводов набора производителей 112, производитель 110 может потреблять данные экземпляра 108. Помимо этого, производитель 110 предоставляет, по меньшей мере, один вывод, причем этот вывод может быть внутренним для экземпляра 108 (и тем самым, модифицировать данные экземпляра 108) и/или может быть внешним; в любом случае, вывод производителя 110 может быть потреблен посредством набора из нуля или более других производителей 114 (упоминаемых как родительские производители для производителя 110)). В некоторых вариантах осуществления, граф производителей, содержащий производитель 110, родительские производители 114 и дочерние производители 112, ассоциативно связан с первым сценарием, имеющим уникальный первый ключ сценария.

Чтобы создавать граф или подграф производителей для второго сценария, отличного от первого сценария, один или более из производителей 110, 112 и 114 могут быть нагружены. Чтобы нагружать производителя, производитель дублируется. В одном варианте осуществления, производитель может быть дублирован посредством создания экземпляра производителя из объявления класса 102, данного метода 104 и объявления 106 зависимостей производителя. Альтернативно, производитель может быть дублирован посредством клонирования или копирования соответствующего существующего производителя для опорного сценария (такого как первый сценарий, описанный выше). Подробности некоторых вариантов осуществления обеих методик поясняются ниже. В общем, все напрямую затрагиваемые производители нагружаются. Помимо этого, производители, зависимые от напрямую затрагиваемых производителей, т.е. косвенно затрагиваемые производители, также могут быть нагружены. В одном варианте осуществления, косвенно затрагиваемый производитель нагружается, если косвенно затрагиваемый производитель попадает на путь между интересующим производителем и напрямую затрагиваемыми производителями. Снова ссылаясь на фиг. 26, допустим, что производитель 110 является напрямую затрагиваемым производителем для второго сценария, в таком случае производитель 110 нагружается с тем, чтобы формировать нагруженный производитель 2610 для второго сценария. Все родительские производители 114 для производителя 110 являются косвенно затрагиваемыми, поскольку все родительские производители 114 зависят от производителя 110. Если родительский производитель в наборе родительских производителей 114 попадает на путь между интересующим производителем и производителем 110, то родительский производитель нагружается. Совокупность нагруженного родительского производителя(ей) для производителя 110 представляется посредством набора 2614 для второго сценария. Кроме того, если есть динамическая зависимость между некоторыми из производителей в наборе 2614, то производители в наборе 2614 могут быть рекурсивно нагружены для второго сценария. Относительно дочерних производителей 112 для производителя 110, дочерние производители 112 могут не быть нагружены для второго сценария, поскольку дочерние производители 112 не являются зависимыми от производителя 110. Тем не менее, если дочерний производитель в наборе 112 является напрямую или косвенно затрагиваемым во втором сценарии, то затрагиваемый дочерний производитель в наборе 112 может быть нагружен, с тем чтобы формировать нагруженный дочерний производитель 2612 для второго сценария. Зависимости между производителями 2610, 2612 и 2614 могут оставаться неизменяемыми во втором сценарии. Альтернативно, некоторые или все зависимости между производителями 2610, 2612 и 2614 могут изменяться во втором сценарии. На фиг. 26 граф производителей второго сценария проиллюстрирован с помощью пунктиров.

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

Фиг. 27A - это блок-схема, иллюстрирующая среду выполнения со средствами поддержки графоориентированного программирования на базе производителей, а также поддержкой сценариев согласно одному варианту осуществления изобретения. Сведения по ссылкам с номером 320, 325, 330, 335, 340, 380, 384 и 345 описаны выше со ссылкой на фиг. 3A. Чтобы поддерживать сценарий, среда 335 выполнения также принимает информацию 328 создания экземпляра сценария. Информация 328 создания экземпляра сценария может быть предоставлена в среду 335 выполнения через различные способы, такие как, например, через клиентский код (такой как графический пользовательский интерфейс (GUI), интерфейс командной строки (CLI) и т.д.) Альтернативно, информация 328 создания экземпляра сценария может быть указана в объявлении зависимостей производителя (таком как операторы объявления зависимостей производителя или код объявления зависимостей производителя). Альтернативно, некоторая или вся информация 328 создания экземпляра сценария может быть указана в исходном коде метода производителя формирования нагруженных производителей. Дополнительные сведения по производителю формирования нагруженных производителей поясняются ниже.

Согласно одному варианту осуществления изобретения, информация 328 создания экземпляра сценария предоставляется в модуль 337 создания сценариев среды 335 выполнения. На основе информации 328 создания экземпляра сценария, модуль 337 создания сценариев создает экземпляры новых сценариев. В некоторых вариантах осуществления, среда 335 выполнения включает в себя структуру 338 отслеживания сценариев, чтобы сохранять ключи сценариев, ссылки на объекты сценариев, которые могут указывать набор из одного или более напрямую затрагиваемых производителей и соответствующих предварительно определенных выводов или преобразований выводов напрямую затрагиваемых производителей, и структуру отслеживания затрагиваемых путей, которая должна затем хранить список производителей, которые затрагиваются посредством сценария. На основе текущего набора из одного или более нагруженных производителей, выводы которых представляют интерес 325, модуль 340 автоматического формирования графов производителей может формировать граф или подграф производителей для одного или более интересующих нагруженных производителей посредством влияния на структуру 338 отслеживания сценариев. Чтобы оценивать воздействие на интересующий нагруженный производитель посредством одного или более предварительно определенных выводов одних или более напрямую затрагиваемых производителей в сценарии, модуль 345 выполнения графа производителей может проходить через граф или подграф производителей, сформированный так, чтобы выполнять производителей, которые затрагиваются, напрямую или косвенно, посредством предварительно определенных выводов или преобразований выводов для сценария.

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

Фиг. 27B - это блок-схема, иллюстрирующая среду выполнения со средствами поддержки графоориентированного программирования на базе производителей, которая также поддерживает инкрементное выполнение и выводы подмененных производителей, а также сценарии согласно одному варианту осуществления изобретения. Сведения по компонентам 320, 325, 350, 352, 354, 360, 365, 380, 382, 384, 370, 396, 390, 392 и 394 пояснены выше со ссылкой на фиг. 3B. Чтобы поддерживать сценарий, информация 328 создания экземпляра сценария вводится в модуль 365 автоматического формирования графов производителей. Подробности некоторых вариантов осуществления информации 328 создания экземпляра сценария описаны выше со ссылкой на фиг. 27A. На основе информации 328 создания экземпляра сценария, модуль 365 автоматического формирования графов производителей может составлять граф или подграф производителей для каждого сценария. Дополнительные сведения по некоторым вариантам осуществления составления графа или подграфа производителей для сценария описываются ниже. Чтобы оценивать воздействие на интересующий нагруженный производитель (т.е. интересующий производитель для конкретного сценария), модуль 370 выполнения графа производителей может проходить через граф или подграф производителей, созданный для того сценария, чтобы выполнять производителей надлежащим образом. Дополнительные сведения по некоторым вариантам осуществления выполнения графа или подграфа производителей для сценария описываются ниже.

В некоторых вариантах осуществления, информация 328 создания экземпляра сценария предоставляется в модуль 390 вывода подмененных производителей, который подменяет вывод одного или более напрямую затрагиваемых производителей в соответствующем сценарии. Подробности работы модуля 390 вывода подмененных производителей описаны выше относительно фиг. 3B.

Фиг. 28A-D иллюстрируют некоторые примерные графы производителей прикладной программы для различных сценариев. Ссылаясь на фиг. 28A, граф производителей для сценария 1 показан наверху, а граф производителей для сценария 2 показан внизу. Сценарии 1 и 2 имеют ключи сценариев "S1" и "S2", соответственно. В некоторых вариантах осуществления, сценарий 1 также упоминается как сценарий по умолчанию или опорный сценарий. Примерная прикладная программа имеет, по меньшей мере, семь производителей, а именно производитель 1 - производитель 7, где производитель 1 напрямую зависит от производителя 3 и производителя 4, производитель 2 напрямую зависит от производителя 4, производитель 3 напрямую зависит от производителя 5 и производителя 6, а производитель 4 напрямую зависит от производителя 7. В сценарии 1, вывод производителя 7 имеет значение X₁, а вывод производителя 1 имеет значение Z₁.

В некоторых вариантах осуществления, нагруженный производитель идентифицируется посредством пары из ключа производителя и ключа сценария. Например, нагруженный производитель 1 в сценарии 2 идентифицируется посредством пары (производитель 1, S2). Нагруженный производитель может быть указан пользователями различными способами, к примеру через клиентский код (например, GUI, CLI и т.д.). Альтернативно, прикладная программа может включать в себя производитель формирования нагруженных производителей, чтобы формировать один или более нагруженных производителей. Примерный вариант осуществления производителя формирования нагруженных производителей, а именно производителя 8, показан на фиг. 28B. Ссылаясь на фиг. 28B, примерный псевдокод производителя 8 показан в правой части чертежа. Первоначально, класс нагруженных производителей задается как имеющий поле, представляющее интересующий ключ производителя, и поле, представляющее сценарий. В текущем примере, производитель 8 является независимым, т.е. оператор объявления зависимостей производителя для производителя 8 является нулевым. В таком случае метод производителя 8 может предоставить информацию сценария для сценария 2, назначать значения для полей нагруженного производителя и выводить совокупность нагруженных производителей.

Снова ссылаясь на фиг. 28A, сценарий 2 задается посредством следующей информации сценария: ключ опорного сценария = нулевой, ключ целевого сценария = S2 и списка напрямую затрагиваемых производителей и их соответствующих выводов. В текущем примере, список напрямую затрагиваемых производителей имеет только один производитель, а именно производитель 7, который имеет указанный вывод X₂. Тем не менее следует принимать во внимание, что в сценарии могут быть несколько напрямую затрагиваемых производителей. В некоторых вариантах осуществления, весь граф производителей воспроизводится для сценария 2 посредством создания каждого из производителя 1 - производителя 7, как проиллюстрировано на фиг. 28A. На графе производителей для сценария 2, вывод напрямую затрагиваемого производителя, т.е. производителя 7, подменяется выводом, указанным в определении сценария 2, т.е. X₂. Интересующий производитель в текущем примере - это производитель 1. Посредством выполнения графа производителей для сценария 2, вывод интересующего нагруженного производителя, т.е. производителя 1 в сценарии 2, задается как Z₂. Альтернативные подходы к тому, чтобы формировать подграфы для сценариев в существующем графе производителей, доступны, и их некоторые варианты осуществления подробно описываются ниже.

Поскольку второй граф производителей создается для сценария 2, модификации, выполняемые для сценария 2 (к примеру, подмена вывода производителя 7) не затрагивают граф производителей для сценария 1. Таким образом, выводы производителей для сценария 1 не пишутся заново посредством выполнения прикладной программы с модификациями, выполненными для сценария 2. По сути, методика создания сценариев полезна в оценке потенциальных или возможных воздействий и/или результатов модификаций без потери существующих выводов производителей в прикладной программе. Может быть полезным фиксировать или сохранять существующие выводы производителей по различным причинам, таким как, например, для того чтобы автоматически определять производную производителей с использованием конечных разностей. Снова ссылаясь на вариант осуществления по фиг. 28A и предполагая, что Z₁, Z₂, X₁ и X₂ - это числовые значения, производная интересующего производителя, т.е. производителя 1, от сценария 1 к сценарию 2, может быть легко вычислена с использованием выводов как из сценария 1, так и из сценария 2 следующим образом:

Производная производителя 1=(Z₂-Z₁)/(X₂-X₁).

Кроме того, высший порядок производных, т.е. производные N-ного порядка (где N - это целое число больше единицы), также могут быть легко вычислены с использованием выводов из различных сценариев. В некоторых вариантах осуществления, перекрестные производные вывода интересующего производителя могут быть вычислены, когда более одного ввода изменяется с одного сценария на другой. Например, допустим, что вводы X₁ и Y₁ изменяются на X₂ и Y₂, соответственно, с одного сценария на другой. Как результат, вывод интересующего производителя изменяется с Z₁ на Z₂. Затем перекрестная производная вывода интересующего производителя может быть вычислена следующим образом:

Перекрестная производная интересующего производителя = (Z₂-Z₁)²/((X₂-X₁)·(Y₂-Y₁)).

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

Как упомянуто выше, альтернативные подходы к тому, чтобы формировать подграф для сценария 2, доступны. Примеры некоторых альтернативных подходов проиллюстрированы на фиг. 28C и 28D.

Ссылаясь на фиг. 28C, методика связывания части графа производителей для сценария 1 (т.е. опорного сценария) используется для того, чтобы формировать граф производителей для сценария 2 (т.е. целевого сценария). Первоначально, среда выполнения может принимать команду создания нагруженного производителя от пользователя через клиентский код, чтобы указывать то, что интересующий производитель - это производитель 1. Альтернативно, производитель формирования нагруженных производителей, такой как производитель 8, может запускать вызов команды создания нагруженного производителя. В ответ на команду создания нагруженного производителя, среда выполнения составляет граф производителей для производителя 1 для сценария 1, который также упоминается как сценарий по умолчанию или опорный сценарий. Затем вторая команда создания нагруженного производителя принимается от пользователя через клиентский код или запускается посредством производителя формирования нагруженных производителей (к примеру, производителя 8), чтобы указывать то, что интересующий производитель - это производитель 2. В ответ на вторую команду создания нагруженного производителя среда выполнения добавляет производитель 2 на граф производителей для сценария 1.

Затем среда выполнения принимает информацию сценария, задающую сценарий 2. С другой стороны, информация сценария может исходить из клиентского кода. Информация сценария указывает ключ опорного сценария как "S1", ключ целевого сценария как "S2", а также список напрямую затрагиваемых производителей и их соответствующих выводов для целевого сценария. Список напрямую затрагиваемых производителей включает в себя только одного производителя в текущем примере, а именно производителя 7, и вывод производителя 7, а именно X₂.

Чтобы оценивать воздействие или результат сценария 2, т.е. изменение вывода производителя 7 на X₂, для производителя, такого как производитель 1, в прикладной программе, производитель 1 идентифицируется как интересующий производитель. Дополнительно, производитель 1 идентифицируется со сценарием, который представляет интерес. Таким образом, нагруженный производитель, который является парой интересующего ключа производителя и ключа сценария, идентифицируется, а именно (производитель 1, S2). В некоторых вариантах осуществления, интересующий производитель идентифицируется пользователями через клиентский код, такой как GUI, CLI и т.д. Альтернативно, интересующий производитель может быть идентифицирован в выводе производителя формирования нагруженных производителей (к примеру, производителя 8).

На основе зависимостей между производителями и информацией сценария, среда выполнения может идентифицировать как напрямую, так и косвенно затрагиваемых производителей для сценария 2. Идентификация напрямую и косвенно затрагиваемых производителей может также упоминаться как отслеживание. Напрямую и косвенно затрагиваемые производители могут быть отслежены с использованием структуры отслеживания затрагиваемых путей (IPTS). В текущем примере, структура отслеживания затрагиваемых путей содержит производителя 7, производителя 4, производителя 1 и производителя 2. Отметим, что производители 1, 2 и 4 являются косвенно затрагиваемыми производителями, тогда как производитель 7 является напрямую затрагиваемым производителем для сценария 2. В некоторых вариантах осуществления, используя список воздействия сценария 2, среда выполнения может идентифицировать напрямую затрагиваемого производителя(ей). Затем среда выполнения может использовать граф производителей для сценария 1, чтобы отслеживать косвенно затрагиваемых производителей посредством пересечения графа производителей для сценария 1 от напрямую затрагиваемых производителей, как указано посредством [B], [C], [D] и [E] на фиг. 28C. Если граф производителей для сценария 1 еще не составлен, среда выполнения может собирать граф производителей для сценария 1 перед отслеживанием косвенно затрагиваемых производителей. Альтернативно, если опорный сценарий не предоставляется или граф производителей для опорного сценария еще не составлен, среда выполнения может создавать интересующий производитель, напрямую затрагиваемый производитель и любые промежуточные производители, попадающие на путь между интересующими производителями и напрямую затрагиваемыми производителями для сценария 2, с помощью соответствующих методов и объявлений зависимостей производителя для вышеуказанных производителей.

В некоторых вариантах осуществления, среда выполнения проходит через структуру отслеживания затрагиваемых путей, чтобы активировать команду создания нагруженного производителя для каждого затрагиваемого производителя в структуре отслеживания затрагиваемых путей. Сформированные нагруженные производители связываются между собой так, чтобы формировать подграф существующего графа производителей для сценария 1. Последовательность вызова не может иметь значения, поскольку новые нагруженные производители (т.е. производители 1, 2, 4 и 7 для сценария 2) связываются между собой по мере того, как они создаются, как указано посредством [G] на фиг. 28C. В некоторых вариантах осуществления, где интересующий производитель не существует в опорном сценарии, такой интересующий производитель не должен отслеживаться в структуре отслеживания затрагиваемых путей. Тем не менее, среда выполнения активирует команду создания нагруженного производителя для такого интересующего производителя, чтобы создавать граф производителей для сценария 2.

Чтобы оптимизировать граф производителей для сценария 2, производители, которые не затрагиваются, напрямую или косвенно, посредством производителя 7, но зависят от интересующего производителя, т.е. производителя 1, не могут быть дублированы или нагружены в сценарии 2. Наоборот, эти производители связываются с графом производителей сценария 2 из сценария 1. В текущем примере, эти производители включают в себя производителей 3, 5 и 6, где производитель 1 напрямую зависит от производителя 3, а производитель 3 напрямую зависит от производителей 5 и 6. Как проиллюстрировано на фиг. 28C, связь создается так, чтобы связывать производитель 3 из сценария 1 с производителем 1 из сценария 2 в [F]. По сути, поднабор графа производителей сценария 1, имеющего производитель 3 и дочерние производители для производителя 3 (т.е. производитель 5 и производитель 6), связывается с графом производителей сценария 2. Другими словами, подграф на графе производителей для сценария 1 создан для сценария 2. Отметим, что воздействия на производителя 7 для сценария 2 не затрагивают производителя 3, поскольку производитель 3 не зависит, напрямую или косвенно, от производителя 7.

Чтобы дополнительно оптимизировать процесс создания графа производителей сценария 2, среда выполнения может ни дублировать, ни нагружать производителей, от которых напрямую или косвенно не зависит интересующий производитель, независимо от того, являются или нет такие производители затрагиваемыми в сценарии 2. Один пример такой оптимизации проиллюстрирован на фиг. 28D. Аналогично фиг. 28C, граф производителей для сценария 1 создается, и производитель 1 идентифицируется как интересующий производитель в сценарии 2, где сценарий 2 задается так, как описано выше. В некоторых вариантах осуществления, команда создания нагруженного производителя активируется для интересующего производителя, т.е. производителя 1, как указано на фиг. 28D. Команда создания нагруженного производителя может быть активирована пользователем через клиентский код или запущена посредством производителя формирования нагруженных производителей, такого как производитель 8 на фиг. 28B.

В зависимости от начального порядка объявления зависимости среда выполнения может активировать команду создания нагруженного производителя для производителей, от которых зависит производитель 1, в этом порядке. Например, если производитель 3 идет перед производителем 4 в начальном объявлении зависимости, команда создания нагруженного производителя активируется сначала для производителя 3, а затем для производителя 4, и наоборот. Когда команда создания нагруженного производителя активируется для производителя 3, связь создается в [F], чтобы связывать производителя 1 в сценарии 2 с производителем 3 в сценарии 1, поскольку производитель 3 не затрагивается в сценарии 2. Когда команда создания нагруженного производителя активируется для производителя 4, нагруженный производитель 4 клонируется в сценарии 2, как указано посредством [G] на фиг. 28D. Чтобы клонировать нагруженный производитель 4 в сценарии 2, среда выполнения может использовать информацию от производителя 4 на графе производителей сценария 1, чтобы делать копию производителя 4 на подграфе для сценария 2. Альтернативно, среда выполнения может создавать новый производитель 4 посредством создания экземпляра производителя 4 на основе объявления зависимостей производителя и объектно-ориентированного исходного кода производителя 4. После того как нагруженный производитель 4 добавлен на граф производителей, команда создания нагруженного производителя активируется для производителя 7, чтобы нагружать производитель 7 для сценария 2, как указано посредством [H] на фиг. 28D. Аналогично производителю 4, производитель 7 может быть нагружен посредством создания экземпляра или клонирования. Отметим, что подграф для сценария 2 теперь полностью составлен, как показано на фиг. 28D, без нагружения производителя 2 в сценарии 2, поскольку интересующий производитель в сценарии 2, а именно производитель 1, не зависит, напрямую или косвенно, от производителя 2, даже при том что производитель 2 косвенно затрагивается посредством производителя 7. Как результат, процесс создания подграфа для сценария 2 дополнительно оптимизируется.

Фиг. 29 - это блок-схема последовательности операций, иллюстрирующая логическую последовательность операций выполнения клиента среды выполнения и его взаимосвязь со средой выполнения со средствами поддержки графоориентированного программирования на базе производителей согласно одному варианту осуществления изобретения. На фиг. 29, пунктирная разделительная линия 600 отделяет логическую последовательность операций выполнения клиента 610 среды выполнения от среды выполнения со средствами поддержки графоориентированного программирования на базе производителей 640. Подробности этапов 615, 620, 625, 630, 645, 650, 655 и 660 описаны выше со ссылкой на фиг. 6. Чтобы поддерживать сценарии, клиент 610 среды выполнения сначала проверяет то, есть ли какой-либо новый сценарий на этапе 616. Если новый сценарий есть, клиент 610 среды выполнения определяет информацию нового сценария на этапе 617. Кроме того, команда создания экземпляра сценария может быть активирована или зарегистрирована в журнале 665 регистрации команд, чтобы создавать экземпляр нового сценария. В ответ на команду создания сценария, среда выполнения 640 создает экземпляр нового сценария на этапе 648. Затем клиент 610 среды выполнения переходит к этапу 615, чтобы продолжать последовательность операций выполнения. В противном случае, клиент 610 среды выполнения пропускает этап 617 и переходит к этапу 615, чтобы продолжать последовательность операций выполнения. На этапе 615, клиент 610 среды выполнения определяет набор из одного или более нагруженных производителей, вывод которых представляет интерес. Затем клиент 610 среды выполнения переходит к этапу 620, чтобы продолжать последовательность операций выполнения, как описано выше со ссылкой на фиг. 6.

Чтобы оценивать воздействия на одного или более интересующих производителей для сценария, модуль выполнения графа производителей активируется на этапе 630. Затем модуль выполнения графа производителей может проходить через граф или подграф производителей сценария, чтобы выполнять всех производителей, которые должны быть выполнены, на основе отслеживания на этапе 660. На этапе 630, модуль выполнения графа производителей активируется, и управление необязательно возвращается к этапу 615, этапу 625 и/или этапу 616.

Фиг. 30 - это блок-схема альтернативной реализации согласно одному варианту осуществления изобретения, который поддерживает сценарий. На фиг. 30 пунктирная разделительная линия 1000 отделяет клиент 1002 среды выполнения от среды выполнения со средствами поддержки графоориентированного программирования на базе производителей 1004. Подробности различных компонентов клиента 1002 среды выполнения и среды 1004 выполнения описаны выше со ссылкой на фиг. 10. Таким образом, последующее описание ориентируется на связанные со сценариями компоненты. В некоторых вариантах осуществления, среда 1004 выполнения дополнительно включает в себя модуль 1096 создания сценариев и структуру 1050 отслеживания сценариев, чтобы поддерживать сценарий.

Как пояснено выше со ссылкой на фиг. 10, модуль 1095 создания классов может создавать экземпляр класса на основе определений 1010 классов. Информация класса, экземпляр которого создан, может храниться в структуре 1092 отслеживания классов. Один примерный вариант осуществления структуры 1092 отслеживания классов показан на фиг. 31A. Ссылаясь на фиг. 31A, ключ 1110 класса и ссылка 1115 на класс (такая как указатель класса) сохраняется в структуре отслеживания классов для каждого класса, экземпляр которого создан. Снова ссылаясь на фиг. 30, определения 1010 классов на стороне клиента 1002 среды выполнения включают в себя код 1018 производителя формирования нагруженных производителей согласно одному варианту осуществления изобретения. Как пояснено выше со ссылкой на фиг. 28B, производитель формирования нагруженных производителей - это производитель, который выводит совокупность нагруженных производителей, каждый из которых включает в себя ключ производителя и ключ сценария. Некоторый примерный псевдокод кода 1018 производителя формирования нагруженных производителей также показан на фиг. 28B. Чтобы поддерживать сценарий, клиент 1002 среды выполнения дополнительно предоставляет команды 1019 создания экземпляров сценария с ключами сценариев. Ключи сценариев могут использоваться при создании новых экземпляров, чтобы ассоциативно связывать экземпляры с соответствующим сценарием(ями). Информация о созданных экземплярах может храниться в структуре 1065 отслеживания экземпляров. Примерный вариант осуществления структуры 1065 отслеживания экземпляров показан на фиг. 31B. Для каждого созданного экземпляра, ключ 1123 сценария, ссылка 1120 на экземпляр и ссылка 1125 на нагруженный экземпляр сохраняются в примерной структуре отслеживания экземпляров на фиг. 31B.

Снова ссылаясь на фиг. 30, клиент 1002 среды выполнения может активировать команду 1019 создания экземпляра сценария с уникальным ключом сценария, чтобы создавать новый сценарий. В ответ на команду 1019 создания экземпляра сценария, модуль 1096 создания сценариев может сохранять информацию нового сценария (такую как информация 328 сценария на фиг. 27A) в структуре 1050 отслеживания сценариев. Примерный вариант осуществления структуры 1050 отслеживания сценариев проиллюстрирован на фиг. 31D. В некоторых вариантах осуществления, структура 1050 отслеживания сценариев включает в себя таблицу, имеющую столбец для ключа сценария, столбец для ссылки на сценарий и столбец для структуры отслеживания затрагиваемых путей, как проиллюстрировано на фиг. 31D. Ключ 3110 сценария может быть уникальным ключом, назначенным сценарию, чтобы идентифицировать сценарий. Ссылка 3112 на сценарий может упоминаться как объект сценария. Структура 3113 отслеживания затрагиваемых путей следит за производителями, затрагиваемыми в соответствующем сценарии.

Фиг. 31E иллюстрирует один вариант осуществления структуры отслеживания объектов сценариев. Структура отслеживания объектов сценариев может включать в себя таблицу, имеющую строку для каждого сценария. Для каждого сценария, ключ 3120 опорного сценария, ключ 3122 целевого сценария и ссылка на список 3124 воздействия сохраняется в структуре отслеживания объектов сценариев. Ключ 3122 целевого сценария идентифицирует сценарий, который должен быть построен. Таким образом, ключ 3122 целевого сценария является таким же, как соответствующий ключ 3110 сценария в структуре отслеживания сценариев на фиг. 31D. Ключ 3120 опорного сценария идентифицирует сценарий, на основе которого может быть построен целевой сценарий. Если нет опорного сценария, то ключ 3120 опорного сценария является нулевым. Ссылка на список воздействия сценария 3124 упоминается как список воздействия сценария, такой как примерный список воздействия, показанный на фиг. 31F.

На фиг. 31F, примерный список воздействия сценария включает в себя столбец для каждого из следующего: ключ 3130 напрямую затрагиваемого производителя, относительный или абсолютный индикатор 3134, экземпляр 3132 вывода, параметр 3136 преобразования и имя метода преобразования и класс 3138 метода. Каждый напрямую затрагиваемый производитель в соответствующем сценарии занимает строку списка воздействия. Ключ 3130 напрямую затрагиваемого производителя идентифицирует напрямую затрагиваемого производителя в сценарии.

В некоторых вариантах осуществления, выходному значению может присваиваться абсолютное значение или относительное значение. Относительный или абсолютный индикатор 3134 указывает то, назначено выходному значению абсолютное значение или относительное значение. Если индикатор 3134 указывает, что он является абсолютным, выходное значение напрямую затрагиваемого производителя обозначается так, чтобы быть экземпляром 3132 вывода, независимо от вводов в напрямую затрагиваемый производитель. В противном случае, параметр 3136 преобразования применяется к текущему выводу напрямую затрагиваемого производителя (т.е. выводу напрямую затрагиваемого производителя для опорного сценария), чтобы преобразовывать текущий вывод напрямую затрагиваемого производителя с использованием метода преобразования с именем метода преобразования и классом 3138 метода. Затем вывод напрямую затрагиваемого производителя для целевого сценария подменяется преобразованным текущим выводом. Отметим, что выводом напрямую затрагиваемого производителя может быть значение (к примеру, числовое значение) или экземпляр. Например, текущим выводом напрямую затрагиваемого производителя является числовое значение, параметром 3136 преобразования является значение множителя, а методом преобразования является умножение, в таком случае выводом напрямую затрагиваемого производителя для целевого сценария является значение, равное произведению значения множителя и значения текущего вывода напрямую затрагиваемого производителя. В другом примере, параметром 3136 преобразования является значение разброса, а методом преобразования является суммирование, в таком случае вывод напрямую затрагиваемого производителя для целевого сценария может быть равен сумме значения разброса и значению текущего вывода напрямую затрагиваемого производителя. Следует принимать во внимание, что выходное значение напрямую затрагиваемого производителя может быть сформировано с помощью других формул в различных вариантах осуществления как функция от значения текущего вывода.

Снова ссылаясь на фиг. 30, модуль 3040 автоматического формирования графов нагруженных производителей осуществляет доступ к структуре 1050 отслеживания сценариев. В ответ на команды создания экземпляра нагруженного производителя с ключами производителей и ключами сценариев 1025, модуль 3040 автоматического формирования графов нагруженных производителей может создавать экземпляр нагруженного производителя на основе информации сценария соответствующего сценария из структуры 1050 отслеживания сценариев, структуры 1092 отслеживания классов, структуры отслеживания методов 1058, структуры 1065 отслеживания экземпляров и экземпляров 1052. Альтернативно, код 1018 производителя формирования нагруженных производителей в определениях 1010 классов обрабатывается посредством среды 1004 выполнения так, чтобы формировать класс производителей 3054 формирования нагруженных производителей и метод, чтобы формировать нагруженных производителей 3056. Сформированные класс и метод вводятся в модуль 3040 автоматического формирования графов нагруженных производителей, который создает экземпляр нагруженного производителя соответствующим образом. Модуль 3040 автоматического формирования графов нагруженных производителей соединяет друг с другом нагруженные производители, экземпляр которых создан, чтобы формировать граф или подграф производителей для соответствующего сценария. Подробности некоторых вариантов осуществления последовательности операций создания экземпляра нагруженного производителя, который поддерживает сценарий, поясняются ниже со ссылкой на фиг. 34A-34G.

Согласно одному варианту осуществления изобретения, граф производителей сохраняется в структуре 1060 графа производителей. Примерная структура графа производителей показана на фиг. 31C. Структура графа производителей является практически такой же, как структура, показанная на фиг. 11C. Поскольку каждый сценарий отслеживается по отдельности в соответствующем графе или подграфе производителей, модуль 3070 выполнения графа нагруженных производителей может проходить через соответствующий граф или подграф производителей для сценария, чтобы выполнять, по меньшей мере, некоторые из нагруженных производителей для сценария, чтобы оценивать воздействия на одного или более интересующих нагруженных производителей для сценария без написания заново или изменения выводов производителей для других сценариев. Подробности некоторых вариантов осуществления последовательности операций выполнения графов производителей, поддерживающих сценарий, поясняются ниже со ссылкой на фиг. 35A и 35B.

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

Фиг. 32 - это блок-схема последовательности операций, иллюстрирующая последовательность операций создания экземпляра сценария согласно одному варианту осуществления изобретения. На этапе 3210, среда выполнения принимает команду создания экземпляра сценария. Среда выполнения затем проверяет, существует ли уже сценарий, идентифицированный посредством команды создания экземпляра сценария, на этапе 3220. Если сценарий уже существует, то последовательность операций создания экземпляра сценария осуществляется на этапе 3290. В противном случае, среда выполнения добавляет информацию сценария, такую как, например, ключ целевого сценария, ключ опорного сценария и ссылку на список воздействия сценария, в структуру отслеживания сценариев на этапе 3230. После этого среда выполнения переходит к этапу 3290, и последовательность операций создания экземпляра сценария осуществляется.

Фиг. 33 - это блок-схема последовательности операций, иллюстрирующая последовательность операций создания экземпляра, которая поддерживает сценарий согласно одному варианту осуществления изобретения. Отметим, что фиг. 33 практически аналогична фиг. 15, и подробности последовательности операций описаны со ссылкой на фиг. 15 выше. Чтобы поддерживать сценарий, среда выполнения создает экземпляр класса и сохраняет экземпляр с его ключом экземпляра, ссылкой на нагруженный экземпляр и ключом(ами) сценария на этапе 3360 на фиг. 33. Как пояснено выше, предусмотрен уникальный ключ сценария для каждого сценария. Таким образом, может быть несколько ключей сценариев, если экземпляр ассоциативно связан с несколькими сценариями. В одном варианте осуществления, ключ экземпляра и ключ(и) сценария сохраняются в структуре отслеживания экземпляров, как проиллюстрировано на фиг. 31B. Ссылаясь на фиг. 31B, структура отслеживания экземпляров включает в себя один столбец для каждого из ключа 1123 сценария, ключа 1120 экземпляра и ссылки 1125 на нагруженный экземпляр.

Фиг. 34A-34G иллюстрируют блок-схемы последовательности операций создания экземпляра нового нагруженного производителя в целевом сценарии согласно одному варианту осуществления изобретения. Фиг. 34A-34C иллюстрируют полную последовательность операций создания экземпляра нового нагруженного производителя, тогда как фиг. 34D-34G иллюстрируют развернутую последовательность определенных операций в полной последовательности операций.

Ссылаясь на фиг. 34A, среда выполнения принимает команду создания нагруженного производителя на этапе 1600. Команда создания нагруженного производителя указывает ключ производителя и ключ целевого сценария. Производитель с ключом производителя и ключом целевого сценария - это нагруженный производитель, который должен быть сформирован посредством команды создания нагруженного производителя. В одном варианте осуществления изобретения, команда создания нагруженного производителя может выполняться в ответ на множество ситуаций. Таблица 3 ниже идентифицирует различные ситуации и передаваемые параметры согласно одному варианту осуществления изобретения.

Таблица 3 Ситуации Вызывающий производитель Вызываемый производитель (который должен быть создан, если уже не существу-ет) Тип вызова Режим связывания Ссылка на производи-тель определения зависимостей Сценарий Интересу-ющий произво-дитель Нет данных Интересующий производитель, который должен быть создан Интере-сующий Нет данных Нет данных Имеется или нулевой Прямой (неподпи-сной) Родительский элемент Дочерний элемент Прямой Режим связывания вызывающих родительских произво-дителей Производитель определения зависимос-тей, предоставляющий зависимость Сценарий вызывающего родительского производителя Прикреп-ляющая подписка Дочерний элемент Родительский элемент (родитель-ский класс и ключ метода из критериев прикрепляющей подписки для родительского производителя, который должен быть создан; ключ экземпляра существующего дочернего вызывающего производителя Прикрепля-ющий Вызываемый родительский произво-дитель (иденти-фикатор аргумента из критериев прикреп-ляющей подписки для родитель-ского произво-дителя, который должен быть создан) Производитель определения зависимос-тей, предоставляющий зависимость Сценарий вызывающего дочернего производителя Подмена Нет данных Производитель, который должен быть подменен Подме-ненный Нет данных Нет данных Имеется или нулевой Непод-писной восходяще объявляемый Дочерний элемент Родительский элемент Непод-писной восходяще объяв-ляемый Режим связывания вызываемых родительских произво-дителей Производитель определения зависимостей, предоставляющий зависимость Сценарий вызывающего дочернего производителя

В ответ на команду создания нагруженного производителя среда выполнения проверяет то, существует ли уже нагруженный производитель (т.е. производитель с ключом производителя и ключом целевого сценария), на этапе 1605. Если нагруженный производитель уже существует, то среда выполнения связывает производитель на графе производителей, если производитель вызывается вследствие зависимости, на этапе 1670. В противном случае, если нагруженный производитель не существует, то среда выполнения идентифицирует как напрямую, так и косвенно затрагиваемых производителей, если производитель - это интересующий производитель, на этапе 1601. Подробности этапа 1601 поясняются ниже со ссылкой на фиг. 34D. Затем среда выполнения переходит к этапу 1602, чтобы обрабатывать сценарии, во время которых среда выполнения задает значение создания производителя. В некоторых вариантах осуществления, создание производителя имеет три возможных значения, а именно "не создавать", "создавать новый" и "клон". Подробности этапа 1602 поясняются ниже со ссылкой на фиг. 34E. Далее среда выполнения проверяет значение создания производителя на этапе 1603. Если создание производителя - это "создавать новый", то среда выполнения переходит к точке входа на фиг. 34B. Если создание производителя - это "клон", то среда выполнения переходит к точке входа B на фиг. 34B. Если создание производителя - это "не создавать", то среда выполнения переходит к этапу 1670.

После этапа 1670 среда выполнения проверяет, подменен ли производитель, имеет ли прикрепляющую подписку или является восходяще объявляемым, на этапе 1675. Если да, среда выполнения отмечает производитель как невыполненный на этапе 1680 и регистрирует производитель в журнале регистрации начала выполнения на этапе 1665. Затем среда выполнения возвращает состояние выполнения производителя на этапе 1660. В противном случае, если производитель не подменен, среда выполнения переходит к этапу 1660, чтобы возвращать состояние выполнения производителя.

Ссылаясь на фиг. 34B, среда выполнения переходит к точке входа A, если создание производителя - это "создавать новый". От точки входа A среда выполнения переходит к этапу 1610, чтобы вызывать модуля создания экземпляров. Затем среда выполнения осуществляет доступ к определению класса экземпляра производителя на этапе 1615. После этого среда выполнения осуществляет доступ к методу и оператору объявления зависимостей производителя для производителя в определении класса на этапе 1620. Далее среда выполнения добавляет производитель на граф производителей целевого сценария на этапе 1625. Среда выполнения переходит к этапу 1604 после этого.

Снова ссылаясь на этап 1603 на фиг. 34A, если создание производителя - это "клон", среда выполнения переходит к точке входа B на фиг. 34B. От точки входа B среда выполнения переходит к этапу 1626, чтобы вызывать модуль создания экземпляров, чтобы создавать пустой экземпляр. Затем среда выполнения копирует информацию из производителя с ключом производителя и ключом опорного сценария, чтобы заполнять пустой экземпляр, на этапе 1627. Далее среда выполнения клонирует производителя с заполненным экземпляром на этапе 1628. Среда выполнения затем добавляет клонированный производитель с ключом целевого сценария на граф производителей на этапе 1629. Среда выполнения переходит к этапу 1604 впоследствии.

На этапе 1604, среда выполнения обрабатывает воздействие, если производитель находится в списке воздействия сценария. Подробности этапа 1604 поясняются ниже со ссылкой на фиг. 34G. Затем среда выполнения обрабатывает критерии фильтрации подписки на этапе 1630 для каждой зарегистрированной подписки. Если производитель вызывается вследствие зависимости, среда выполнения связывает производителя в граф производителей на этапе 1635. Затем среда выполнения переходит к точке входа C.

Ссылаясь на фиг. 34C, среда выполнения переходит к этапу 1640 из точки входа C, чтобы отмечать производитель как невыполненный. В некоторых вариантах осуществления, среда выполнения может принимать команду отмены подмены производителя на этапе 1690. В ответ на команду отмены подмены производителя, среда выполнения может отмечать производитель как неподмененный на этапе 1695 и затем переходит к этапу 1640.

От этапа 1640 среда выполнения переходит к этапу 1645, чтобы проверять, имеет ли производитель какие-либо зависимости и является неподмененным. Если производитель не имеет зависимостей и является неподмененным, то среда выполнения переходит к точке входа D, чтобы возвращаться к этапу 1665 на фиг. 34A. В противном случае, среда выполнения переходит к этапу 1650. На этапе 1650, для каждой зависимости в объявлении зависимости, которая должна быть определена теперь, среда выполнения определяет число производителей и активирует команду создания нагруженного производителя для каждого из них. Если все зависимые производители существуют и выполнены, среда выполнения добавляет производитель в журнал регистрации начала выполнения на этапе 1655 и переходит к точке входа E, чтобы возвращаться к этапу 1660 на фиг. 34A.

Фиг. 34D иллюстрирует расширенную блок-схему последовательности операций этапа 1601 согласно одному варианту осуществления изобретения. Среда выполнения сначала находит структуры отслеживания затрагиваемых путей с использованием структуры отслеживания сценариев и ключа сценария на этапе 3405. Затем среда выполнения определяет на этапе 3410, создан ли уже экземпляр структуры отслеживания затрагиваемых путей в структуре отслеживания сценариев. Если экземпляр структуры отслеживания затрагиваемых путей уже создан, то как напрямую, так и косвенно затрагиваемые производители уже идентифицированы. Таким образом, среда выполнения переходит к этапу 3419, чтобы завершать последовательность операций. В противном случае, среда выполнения переходит к этапу 3412. На этапе 3412, экземпляр структуры отслеживания затрагиваемых путей создается и сохраняется в структуре отслеживания сценариев. Затем среда выполнения переходит к этапу 3413. Для каждого напрямую затрагиваемого производителя в определении сценария среда выполнения выполняет поиск производителя с соответствующим ключом производителя и ключом опорного сценария в определении сценария. Среда выполнения определяет то, существует ли такой производитель, на этапе 3415. Если такой производитель существует, среда выполнения добавляет производитель в структуру отслеживания затрагиваемых путей наряду со всеми предками на этапе 3417 и затем переходит к этапу 3418. В противном случае, среда выполнения пропускает этап 3417 и переходит к этапу 3418. На этапе 3418, среда выполнения проверяет то, есть ли еще напрямую затрагиваемый производитель в определении сценария. Если есть, то среда выполнения возвращается к этапу 3413, чтобы повторять операции, описанные выше. В противном случае, среда выполнения переходит к этапу 3419, чтобы завершать последовательность операций.

Фиг. 34E иллюстрирует расширенную блок-схему последовательности операций этапа 1602 согласно одному варианту осуществления изобретения. Среда выполнения проверяет то, является ли структура отслеживания затрагиваемых путей пустой, на этапе 3420. Если структура отслеживания затрагиваемых путей является пустой, среда выполнения переходит к этапу 3429. В противном случае, среда выполнения проверяет то, находится ли производитель с ключом опорного сценария в структуре отслеживания затрагиваемых путей, на этапе 3422. Если да, то среда выполнения задает создание производителя как "клон" на этапе 3424. В противном случае, среда выполнения проверяет то, существует ли производитель на графе производителей с опорным сценарием, на этапе 3426. Если он существует, то среда выполнения задает создание производителя как "не создавать" на этапе 3428. Это представляет собой оптимизацию, которая приводит к дублированию только части графа производителей для целевого сценария. Производители, которые не созданы или клонированы, могут быть связаны с подграфом для целевого сценария из опорного сценария. В противном случае, среда выполнения переходит к этапу 3429. На этапе 3429, среда выполнения задает создание производителя как "создавать новый".

Фиг. 34F иллюстрирует расширенное представление этапа 1605 на фиг. 34A согласно одному варианту осуществления изобретения. На этапе 1605, среда выполнения проверяет то, существует ли уже нагруженный производитель. В некоторых вариантах осуществления, среда выполнения проверяет то, существует ли уже комбинация ключа класса, ключа экземпляра, ключа метода и ключа сценария в таблице производителя. Если комбинация существует, нагруженный производитель существует. В противном случае, нагруженный производитель не существует.

Фиг. 34G иллюстрирует расширенную блок-схему последовательности операций этапа 1604 согласно одному варианту осуществления изобретения. В некоторых вариантах осуществления, предусмотрены соответствующие специальные интерфейсы для того, чтобы получать и задавать выводы производителей. На этапе 3430, среда выполнения проверяет то, является ли если воздействие на производителя относительным. Если нет, то воздействие на производителя является абсолютным. Таким образом, среда выполнения назначает экземпляр вывода из списка воздействия сценария в качестве нового вывода производителя в целевом сценарии на этапе 3436. Затем среда выполнения переходит к этапу 3440. В противном случае, воздействие на производителя является относительным, и среда выполнения получает текущий вывод производителя на этапе 3432. Затем среда выполнения формирует новый вывод производителя с использованием текущего вывода и соответствующего метода преобразования и соответствующего параметра преобразования в списке воздействия сценария на этапе 3434. После этого среда выполнения переходит к этапу 3440.

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

На этапе 3440, среда выполнения задает вывод производителя в новом выходном значении, сформированном в кэше выводов производителей и в экземпляре, если вывод является полем. Среда выполнения затем отмечает производитель как подмененный на этапе 3442 и переходит к этапу 1630 на фиг. 34B.

Фиг. 35A-35B являются блок-схемами последовательности операций, иллюстрирующими последовательность операций выполнения графа нагруженных производителей согласно одному варианту осуществления изобретения. На этапе 2200, среда выполнения выбирает набор вариантов производителей, которые должны быть выполнены, на основе производителей на журнале регистрации начала выполнения в качестве текущего набора вариантов производителей. Затем среда выполнения выбирает поднабор производителей из текущего набора вариантов производителей, которые готовы быть выполненными, в качестве текущего набора готовых производителей на этапе 2205. Для каждого производителя в текущем наборе готовых производителей, среда выполнения проверяет тип производителя на этапе 2210. В одном варианте осуществления, предусмотрено три типа производителей, а именно стандартные производители, производители формирования нагруженных производителей и производители объявления зависимости.

Если производитель - это стандартный производитель, среда выполнения переходит к этапу 2215, чтобы выполнять производитель. Затем среда выполнения отмечает все родительские элементы, которые имеют зависимость на основе поглощающей подписки от выполненного производителя, как незавершенные на этапе 2220 и переходит к точке входа A.

Если производитель - это производитель формирования нагруженных производителей, среда выполнения переходит к этапу 3710, чтобы выполнять производитель. Затем среда выполнения помечает все родительские элементы, которые имеют зависимость на основе поглощающей подписки от выполненного производителя, как незавершенные на этапе 3720. Далее среда выполнения активирует команды создания нагруженного производителя для обнаруженных производителей, регистрирует и обрабатывает подписки на этапе 3730. Затем среда выполнения добавляет в набор вариантов производителей на основе производителей, заново добавленных в журнал регистрации начала выполнения, на этапе 3740. Среда выполнения после этого переходит к точке входа A.

Если производитель - это производитель объявления зависимости, среда выполнения подготавливает производитель определения зависимостей на этапе 2225. Затем среда выполнения выполняет производитель определения зависимостей, чтобы разрешать все неразрешенные зависимости, готовые быть разрешенными, на этапе 2230. Далее среда выполнения активирует команды создания нагруженного производителя для обнаруженных производителей, регистрирует и обрабатывает подписки на этапе 2235. Среда выполнения добавляет производители, заново добавленные в журнал регистрации начала выполнения, в набор вариантов производителей на этапе 2240. Среда выполнения затем переходит к точке входа A.

Ссылаясь на фиг. 35B, среда выполнения переходит от точки входа к этапу 2245. На этапе 2245, среда выполнения отмечает производители как выполненные и обновляет кэширование выводов производителей и кэширование экземпляров по мере необходимости. Кроме того, среда выполнения добавляет все родительские производители в набор вариантов производителей, которые должны быть выполнены, и помечает как невыполненные. Среда выполнения дополнительно удаляет выполненные производители из текущих наборов вариантов и готовых производителей. От этапа 2245, среда выполнения переходит к этапу 2250, чтобы проверять то, является ли набор вариантов производителей пустым. Если не пустой, среда выполнения переходит к этапу 2205 через точку входа B, чтобы повторять последовательность операций, описанную выше. Если набор вариантов производителей является пустым, среда выполнения переходит к этапу 2255, чтобы проверять то, завершена ли вся подписка. Если нет, среда выполнения обрабатывает незавершенные производители поглощающей подписки на этапе 2260 и затем возвращается к этапу 2205 через точку входа B. В противном случае, т.е. когда все подписки завершены, среда выполнения переходит к этапу 2248. На этапе 2248, структура отслеживания сценариев сканируется, и все структуры отслеживания путей экземпляров отключаются. Затем среда выполнения переходит к этапу 2265, чтобы завершать последовательность операций.

Процедурные языки

Как ранее указано, надлежащим образом написанный код процедурного языка, нерефлексивного объектно-ориентированного языка и нерефлексивного основанного на объектах языка может быть преобразован в код рефлексивного объектно-ориентированного языка. В качестве примера, класс может быть эмулирован через структуру данных и набор статических функций, имеющих в качестве первого параметра указатель на экземпляр структуры данных. Среди этих функций предусмотрены конструктор и деструктор. Конструкторы активируются посредством среды выполнения после выделения указателя на структуру данных и предоставляют значения по умолчанию для элементов в структуре данных, а деструкторы активируются посредством среды выполнения перед высвобождением указателя на структуру данных. Каждый класс имеет свое описание через файл, который включает в себя: 1) структуру данных; 2) другую структуру, описывающую класс, хранящий размер структуры и набор указателей на функции; 3) список статических функций со своим кодом (для нерефлексивных объектно-ориентированных языков и нерефлексивных основанных на объектах языков, код статических функций должен формироваться автоматически посредством сканирования методов действительного класса и создания для каждого метода статической функции, которая выполняет фактический вызов связанного метода); и 4) примечания перед каждой функцией (комментарии содержат объявления зависимостей производителя) вместе с их типом (конструктор, деструктор, свойство и т.д.). В дополнение к этому определению класса, в процедурном, нерефлексивном объектно-ориентированном или нерефлексивном основанном на объектах языке также реализуется динамический вызов. В частности, компилятор формирует следующий код инициализации для каждого класса, код, который вызывается один раз (посредством модуля создания классов) для того, чтобы: 1) создавать экземпляр структуры, описывающей класс, заполнять указатели на функции фактическими статическими функциями; 2) регистрировать экземпляр этой структуры в таблице классов (структуре отслеживания классов) с ключом, соответствующим имени класса; и 3) регистрировать все указатели на функции в таблице функций (структуре отслеживания методов) с ключом, соответствующим имени функции (наряду с ArgumentDependencies, SequencingDependencies, FieldDependencies, UpwardDependencies, WeaklyConstrainedDependencies, ключом класса вывода и дополнительными примечаниями). Преобразование предоставляет возможность реализации в среде выполнения универсальных функций вызова, допускающих: 1) создание экземпляра класса по имени (посредством модуля создания экземпляров) (в частности, среда выполнения: a) выделяет память согласно размеру структуры данных и добавляет заголовок к указателю, чтобы сохранять указатель на структуру, описывающую класс, и тем самым реализует интеллектуальные указатели (к примеру, указатели, допускающие выполнение запроса относительно их типов); и b) активирует надлежащие функции конструктора после извлечения релевантного указателя на статическую функцию из таблицы); и 2) вызов метода по имени при условии, что все параметры переданы надлежащим образом после извлечения релевантного указателя на статическую функцию из таблицы. Надлежащая передача параметров для функций, идентифицированных посредством указателей на функции, должна выполняться через язык ассемблера проталкиванием и выталкиванием элементов в/из стека для параметров ввода и вывода. Метод, описанный выше, предполагает наличие понятия структур данных и наличие понятия указателей на функции на процедурном, нерефлексивном объектно-ориентированном или нерефлексивном основанном на объектах языке.

Примерный синтаксис объектно-ориентированного исходного кода

A. Клиентский код

В одном варианте осуществления изобретения, клиентский код принимает следующий синтаксис (показан в форме заголовка):

ProducerKey

New (String ClassKey, InstanceKey InstanceKey, String MethodKey);

Runtime

New ()

AddProducerOfInterest (ProducerKey ProducerOfInterestKey);

SetProducerOutput (ProducerKey ProducerToOverrideKey, Object ProducerOutputInstance);

Execute ();

ProducerKey и Runtime - это классы, тогда как New, AddProducerOfInterest, SetProducerOutput и Execute - это методы. AddProducerOfInterest инструктирует вызов команды создания производителя с соответствующими значениями для производителя соответствующей ситуации в таблице 2. ProducerOutputInstance - это экземпляр класса вывода подмененных производителей. Таким образом, его экземпляр создается через соответствующий конструктор класса вывода производителей.

B. Операторы

1. Синтаксис оператора объявления зависимости

argumentDependency = "Argument1Dependency; Argument2Dependency;...";

fieldDependency = "FieldDependency1;FieldDependency2;...";

sequencingDependency = "SequencingDependency1; SequencingDependency2;...";

upwardDependency = "UpwardDependency1; UpwardDependency2;...";

weeklyConstrainedDependency = "WeeklyConstrainedDependency1; WeeklyConstrainedDependency2;...";

unConstrainedDependency = "unConstrainedDependency1; unConstrainedDependency2;...";

2. Синтаксис зависимостей

a. Синтаксис fieldDependencyX, sequencingDependencyX, upwardDependencyX, weeklyConstrainedDependencyX, unConstrainedDependencyX:

#C:'ClassKey':: #I:'InstanceKey':: #M:'MethodKey'

b. Синтаксис argumentXDependency:

ArgumentID:: #C:'ClassKey':: #I:'InstanceKey':: #M:'MethodKey'

В одном варианте осуществления изобретения, ArgumentID опускается в синтаксисе, и порядок, в котором argumentDependencies объявлены, представляет ArgumentID. ArgumentID, таким образом, добавлен для того, чтобы повысить удобочитаемость.

3. Сокращенные и несокращенные элементы

Синтаксис такой же, как для несокращенных элементов, но использование #S:: перед ключом производителя указывает сокращенный элемент.

a. Синтаксис fieldDependencyX, sequencingDependencyX, upwardDependencyX, weeklyConstrainedDependencyX, unConstrainedDependencyX:

#S:: #C:'ClassKey':: #I:'InstanceKey':: #M:'MethodKey'

b. Синтаксис argumentXDependency:

ArgumentID:: #S:: #C:'ClassKey':: #I:'InstanceKey':: #M:'MethodKey'

В этом случае, ключ производителя, указанный посредством зависимости, не является производителем определения зависимостей. Другие реализации синтаксиса могут допускать, что сокращенный элемент - это зависимость по умолчанию для определенного типа зависимости (такой как поле), и опускать #S::. В этом случае, #DDP может использоваться для того, чтобы указывать наличие DDP.

4. Условные и безусловные элементы

Как отмечено ранее, может помещаться перед условным элементом.

a. Пример условного класса и метода:

1) Синтаксис fieldDependencyX, sequencingDependencyX, upwardDependencyX, weeklyConstrainedDependencyX, unConstrainedDependencyX:

#C: 'ClassDeterminationMethodKey':: #I:'InstanceKey':: #M: 'MethodDeterminationMethodKey'

2) Синтаксис argumentXDependency

ArgumentID:: #C: 'ClassDeterminationMethodKey':: #I:'InstanceKey':: #M: 'MethodDeterminationMethodKey'

b. Пример условного метода

1) Синтаксис fieldDependencyX, sequencingDependencyX, upwardDependencyX, weeklyConstrainedDependencyX, unConstrainedDependencyX:

#C:'ClassKey':: #I:'InstanceKey':: #M: 'MethodDeterminationMethodKey'

2) Синтаксис argumentXDependency:

ArgumentID:: #C:'ClassKey':: #I:'InstanceKey':: #M: 'MethodDeterminationMethodKey'

c. Пример условного экземпляра

1) Синтаксис fieldDependencyX, sequencingDependencyX, upwardDependencyX, weeklyConstrainedDependencyX, unConstrainedDependencyX:

#C:'ClassKey':: #I: 'InstanceDeterminationMethodKey':: #M: 'MethodKey'

2) Синтаксис argumentXDependency

ArgumentID:: #C:'ClassKey':: #I: 'InstanceDeterminationMethodKey':: #M: 'MethodKey'

5. Сокращенная методика

Такие элементы, как класс, экземпляр или метод, которые считаются идентичными элементам родительских производителей, опускаются. Это типично имеет место для сокращенных полей. Примеры, приведенные ниже, комбинируют сокращенную методику и сокращенное объявление (сокращенный элемент иллюстрируется посредством #S:):

a. Пример, где класс и экземпляр опускаются

1) Синтаксис fieldDependencyX, sequencingDependencyX, upwardDependencyX, weeklyConstrainedDependencyX, unConstrainedDependencyX:

#S:: #M:'MethodKey'

2) Синтаксис argumentXDependency:

ArgumentID:: #S:: #M:'MethodKey'

b. Пример, где класс опускается

1) Синтаксис fieldDependencyX, sequencingDependencyX, upwardDependencyX, weeklyConstrainedDependencyX, unConstrainedDependencyX:

#S:: #I:'InstanceKey':: #M:'MethodKey'

2) Синтаксис argumentXDependency:

ArgumentID:: #S:: #I:'InstanceKey':: #M:'MethodKey'

Альтернативные варианты осуществления

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

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

Иллюстрации к изобретению RU 2 438 161 C2

Реферат патента 2011 года ИНФРАСТРУКТУРА ГРАФООРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ НА ОСНОВЕ ПРОИЗВОДИТЕЛЕЙ С ПОДДЕРЖКОЙ СЦЕНАРИЕВ

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

Формула изобретения RU 2 438 161 C2

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

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

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

4. Способ по п.3, в котором создание целевого сценария содержит этапы, на которых:
- определяют то, какие производители из производителей на первом графе производителей должны затрагиваться посредством выводов одного или более напрямую затрагиваемых производителей, с помощью первого графа производителей; и
- регистрируют затрагиваемых производителей в структуре отслеживания производителей воздействия.

5. Способ по п.4, в котором создание целевого сценария содержит этапы, на которых:
- создают второй граф производителей, имеющий копию, по меньшей мере, интересующего производителя, одного или более напрямую затрагиваемых производителей и любого из затрагиваемых производителей в структуре отслеживания производителей воздействия, от которой зависит интересующий производитель; и
- изменяют выводы копии одного или более напрямую затрагиваемых производителей согласно информации в списке воздействия.

6. Способ по п.5, в котором изменение выводов копии одного или более напрямую затрагиваемых производителей согласно информации в списке воздействия содержит этап, на котором:
- подменяют выводы копии одного или более напрямую затрагиваемых производителей на втором графе производителей предварительно определенным значением, указанным посредством информации в списке воздействия.

7. Способ по п.5, в котором изменение выводов копии одного или более напрямую затрагиваемых производителей согласно информации в списке воздействия содержит этапы, на которых:
- определяют выводы производителей в первом сценарии; и
- формируют вывод копии напрямую затрагиваемого производителя в целевом сценарии с использованием выводов производителей в первом сценарии и информации в списке воздействия.

8. Способ по п.5, в котором создание второго графа производителей содержит этап, на котором:
- связывают одного или более производителей на первом графе производителей со вторым графом производителей, при этом один или более производителей являются независимыми от напрямую затрагиваемого производителя.

9. Способ по п.5, в котором создание второго графа производителей содержит этап, на котором:
- клонируют интересующего производителя и любого из затрагиваемых производителей, от которых зависит интересующий производитель, с помощью первого графа производителей.

10. Способ по п.5, в котором создание второго графа производителей содержит этап, на котором:
- создают интересующего производителя и затрагиваемых производителей, от которых интересующий производитель зависит, из определения метода и объявления зависимости метода каждого интересующего производителя и затрагиваемых производителей, от которых зависит интересующий производитель.

11. Способ по п.5, в котором моделирование дополнительно содержит этапы, на которых:
- выполняют прикладную программу в целевом сценарии с помощью измененных выводов копии одного или более напрямую затрагиваемых производителей, чтобы определять вывод копии интересующего производителя на втором графе производителей, при сохранении существующих выводов интересующего производителя, одного или более напрямую затрагиваемых производителей и затрагиваемых производителей для первого сценария;
- сохраняют вывод копии интересующего производителя для целевого сценария в кэше при фиксировании существующего вывода интересующего производителя для первого сценария в кэше;
- сохраняют измененный вывод копии одного или более напрямую затрагиваемых производителей для целевого сценария в кэше при фиксировании существующего вывода одного или более напрямую затрагиваемых производителей для первого сценария в кэше; и
- сохраняют выводы копий промежуточных производителей на пути между интересующим производителем и одним или более напрямую затрагиваемых производителей для целевого сценария в кэше при фиксировании существующих выводов промежуточных производителей для первого сценария в кэше.

12. Способ по п.11, дополнительно содержащий этап, на котором:
- автоматически определяют производную вывода интересующего производителя от первого сценария к целевому сценарию, используя вывод копии интересующего производителя для целевого сценария и вывод интересующего производителя для первого сценария.

13. Способ по п.12, дополнительно содержащий этап, на котором:
- автоматически и рекурсивно определяют, по меньшей мере, одно из производной N-го порядка и перекрестной производной с использованием производной вывода интересующего производителя от первого сценария к целевому сценарию, где N - это целое число больше единицы.

14. Способ по п.5, в котором моделирование прикладной программы содержит этап, на котором выполняют производителя формирования нагруженных производителей, чтобы динамически создавать, по меньшей мере, одного из производителей на втором графе производителей.

15. Система для моделирования изменения в выполняющейся прикладной программе, написанной в объектно-ориентированном коде, при этом система содержит:
- процессор;
- память, соединенную с процессором, причем память хранит выполняемые процессором инструкции, которые, будучи выполненными, реализуют:
- среду выполнения, чтобы выполнять объектно-ориентированный код с объявлениями зависимостей производителя для методов, при этом производитель является конструкцией с возможностью создания экземпляра среды выполнения, которая включает в себя, по меньшей мере, экземпляр и метод, ассоциативно связанный с экземпляром, при этом каждое объявление зависимостей производителя для данного метода идентифицирует набор из нуля или более производителей, и при этом упомянутая среда выполнения включает в себя модуль создания новых сценариев, чтобы принимать информацию сценария целевого сценария и, в ответ на команду создания экземпляра сценария, создавать экземпляр целевого сценария;
- модуль автоматического формирования графов нагруженных производителей, соединенный с модулем создания сценариев, чтобы принимать текущего выбранного производителя с интересующим выводом и строить граф производителей для целевого сценария с использованием информации сценария, причем граф производителей включает в себя копию каждого текущего выбранного производителя, одного или более производителей, выводы которых изменены в целевом сценарии согласно информации сценария, и промежуточных производителей между одним или более производителями и текущим выбранным производителем; и
- модуль автоматического выполнения графов нагруженных производителей, соединенный с модулем автоматического формирования графов нагруженных производителей, чтобы принимать измененные выводы одного или более производителей на графе производителей для целевого сценария и применять измененные выводы к производителям графа производителей для целевого сценария, чтобы определять вывод текущего выбранного производителя в целевом сценарии.

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

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

18. Система по п.15, в которой среда выполнения дополнительно содержит:
- структуру графа производителей, соединенную с модулем автоматического формирования графов нагруженных производителей, чтобы сохранять граф производителей для целевого сценария без повторного написания каких-либо существующих графов производителей, сохраненных в нем, при этом структура графа производителей дополнительно содержит структуру кэширования выводов производителей, чтобы сохранять вывод текущего выбранного производителя, выводы промежуточных производителей и измененные выводы одного или более производителей для целевого сценария без перезаписывания каких-либо существующих выводов текущего выбранного производителя, промежуточных производителей и одного или более производителей, сохраненных в нем.

19. Система по п.15, в которой среда выполнения дополнительно содержит:
- структуру отслеживания сценариев, соединенную с модулем создания сценариев, при этом модуль создания сценариев выполнен с возможностью создавать экземпляр целевого сценария посредством добавления информации сценария в структуру отслеживания сценариев.

20. Система по п.15, дополнительно содержащая:
- вторую среду выполнения, выполненную с возможностью загружать и создавать экземпляры классов, активировать методы и выполнять анализ, по меньшей мере, для одного из классов и методов, при этом вторая среда выполнения является логически отделенной от среды выполнения.

21. Система по п.15, в которой среда выполнения дополнительно выполнена с возможностью загружать и создавать экземпляры классов, активировать методы и выполнять анализ, по меньшей мере, для одного из классов и методов.

22. Система по п.15, дополнительно содержащая операционную систему, при этом среда выполнения интегрирована в операционную систему.

23. Система для моделирования изменения в выполняющейся прикладной программе, написанной в объектно-ориентированном коде, при этом система содержит:
- процессор;
- машиночитаемый носитель, соединенный с процессором, для хранения объектно-ориентированного кода, включающего в себя:
- множество определений классов множества классов, причем каждое из множества определений классов включает в себя:
- набор из одного или более полей,
- набор из одного или более методов, и
- объявление зависимостей производителя для каждого из упомянутого набора методов, при этом объявление зависимостей производителя для данного одного из упомянутых методов используется посредством среды выполнения для того, чтобы идентифицировать набор из нуля или более производителей, при этом производитель является конструкцией с возможностью создания экземпляра среды выполнения, которая включает в себя, по меньшей мере, экземпляр одного из множества классов и метод, ассоциативно связанный с экземпляром; и
- причем первое из упомянутого множества определений классов задает первый из множества классов, имеющий один или более методов формирования нагруженного производителя, чтобы формировать набор из одного или более нагруженных производителей, причем каждый из упомянутых одного или более методов формирования нагруженного производителя включает в себя код, чтобы идентифицировать интересующего производителя, который является производителем с выводом, интересующим в настоящий момент, и задавать целевой сценарий так, что среда выполнения способна выполнять метод, чтобы оценивать воздействие на интересующего производителя для целевого сценария.

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

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

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

Документы, цитированные в отчете о поиске Патент 2011 года RU2438161C2

СПОСОБ ПОЛУЧЕНИЯ ОБЪЕКТНОГО КОДА	2000	Волконский В.Ю. Останевич А.Ю. Сушенцов А.Л.	RU2206119C2
US 5966072 А, 12.10.1999
Способ обработки целлюлозных материалов, с целью тонкого измельчения или переведения в коллоидальный раствор	1923	Петров Г.С.	SU2005A1
СПОСОБ ВЫДЕЛЕНИЯ .ii-КСИЛОЛА	0		SU201359A1

RU 2 438 161 C2

Авторы

Шамье Фади

Эдде Элиа

Даты

2011-12-27—Публикация

2007-11-30—Подача

название	год	авторы	номер документа
ГРАФООРИЕНТИРОВАННОЕ ПРОГРАММИРОВАНИЕ И ВЫПОЛНЕНИЕ НА ОСНОВЕ ПРОИЗВОДИТЕЛЕЙ	2007	Шамье Фади Эдде Элиа	RU2445682C2
ПАРАЛЛЕЛИЗАЦИЯ И ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА В ИНФРАСТРУКТУРЕ ГРАФООРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ НА ОСНОВЕ ПРОИЗВОДИТЕЛЕЙ	2007	Шамье Фади Эдде Элиа	RU2435201C2
ИСПОЛЬЗОВАНИЕ АТРИБУТОВ ДЛЯ ИДЕНТИФИКАЦИИ И ОТБОРА ПОДКЛЮЧАЕМЫХ ВЫПОЛНЯЕМЫХ ФУНКЦИЙ	2006	Киммерли Рэнди С.	RU2427030C2
ИНТЕРФЕЙС ПРОГРАММИРОВАНИЯ ДЛЯ КОМПЬЮТЕРНОЙ ПЛАТФОРМЫ	2004	Богдан Джеффри Л. Релая Роберт А.	RU2371758C2
МОДЕЛЬ ДАННЫХ ДЛЯ ОБЪЕКТНО-РЕЛЯЦИОННЫХ ДАННЫХ	2006	Нори Анил Кумар Дим Майкл Э. Пиццо Майкл Дж. Анонсен Стивен П. Хартер Стивен В.	RU2421798C2
СИСТЕМА И СПОСОБ ДЕКЛАРАТИВНОГО ОПРЕДЕЛЕНИЯ И ИСПОЛЬЗОВАНИЯ ПОДКЛАССОВ ВНУТРИ РАЗМЕТКИ	2003	Рамани Сандарам Релая Роберт А. Богдан Джеффри Л.	RU2347269C2
СОЗДАНИЕ И ВЫПОЛНЕНИЕ РЕЖИМА АНИМАЦИИ ДЛЯ ГРАФИЧЕСКОГО ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА	2003	Кэлкинс Мэтт Беда Джозеф Стивен Iii Галло Кевин Вонг Гилман К. Бланко Леонардо Эстебан	RU2327218C2
ИСЧЕРПЫВАЮЩАЯ АВТОМАТИЧЕСКАЯ ОБРАБОТКА ТЕКСТОВОЙ ИНФОРМАЦИИ	2014	Даниэлян Татьяна Владимировна Старостин Анатолий Сергеевич Зуев Константин Алексеевич Анисимович Константин Владимирович Селегей Владимир Павлович	RU2662699C2
СПОСОБ ФОРМИРОВАНИЯ ИЕРАРХИЧЕСКОЙ СТРУКТУРЫ ДАННЫХ, СПОСОБ ПОИСКА ДАННЫХ С ПОМОЩЬЮ ИЕРАРХИЧЕСКОЙ СТРУКТУРЫ ДАННЫХ, СЕРВЕР И ПОСТОЯННЫЙ МАШИНОЧИТАЕМЫЙ НОСИТЕЛЬ	2014	Налчаджи Леонид Леонидович	RU2632414C2
СПОСОБ И СИСТЕМА УПРАВЛЕНИЯ СТАТИЧЕСКИМИ СТРУКТУРАМИ ДАННЫХ УНАСЛЕДОВАННОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ В СРЕДАХ ДИНАМИЧЕСКИХ ЗАГРУЗЧИКОВ КЛАССОВ	2011	Ламберт Марк Доменек Лоран	RU2571592C2

ИНФРАСТРУКТУРА ГРАФООРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ НА ОСНОВЕ ПРОИЗВОДИТЕЛЕЙ С ПОДДЕРЖКОЙ СЦЕНАРИЕВ Российский патент 2011 года по МПК G06F9/44

Описание патента на изобретение RU2438161C2

Похожие патенты RU2438161C2

Иллюстрации к изобретению RU 2 438 161 C2

Реферат патента 2011 года ИНФРАСТРУКТУРА ГРАФООРИЕНТИРОВАННОГО ПРОГРАММИРОВАНИЯ НА ОСНОВЕ ПРОИЗВОДИТЕЛЕЙ С ПОДДЕРЖКОЙ СЦЕНАРИЕВ

Формула изобретения RU 2 438 161 C2

Документы, цитированные в отчете о поиске Патент 2011 года RU2438161C2

RU 2 438 161 C2