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

Авторы патента:

ЭДДЕ Элиа (FR)

ШАМЬЕ Фади (FR)

G06F9/44 - устройства для выполнения специальных программ

Владельцы патента RU 2445682:

МЮРЕКС С.А.С. (FR)

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

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

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

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

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

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

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

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

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

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

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

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

Ранние среды выполнения, такие как 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 идентифицирует затрагиваемые части исходного кода с использованием схемы последовательности. Артефакт проектирования используется для сопровождения кода и/или разбора конструкции статического исходного кода.

КРАТКАЯ СУЩНОСТЬ ИЗОБРЕТЕНИЯ

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

КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ

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

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

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

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

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

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

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

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

Фиг.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 согласно одному варианту осуществления изобретения.

ПОДРОБНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ

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

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

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

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

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

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

Обзор

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

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

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

Фиг.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).

На этапе 2016 определяется то, вызвана ли последовательность операций вследствие прикрепляющей подписки или неподписной восходяще объявляемой ситуации. Если нет, управление переходит к этапу 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.

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

Как ранее указано, надлежащим образом написанный код процедурного языка, нерефлексивного объектно-ориентированного языка и нерефлексивного основанного на объектах языка может быть преобразован в код рефлексивного объектно-ориентированного языка. В качестве примера класс может быть эмулирован через структуру данных и набор статических функций, имеющих в качестве первого параметра указатель на экземпляр структуры данных. Среди этих функций предусмотрены конструктор и деструктор. Конструкторы активируются посредством среды выполнения после выделения указателя на структуру данных и предоставляют значения по умолчанию для элементов в структуре данных, а деструкторы активируются посредством среды выполнения перед высвобождением указателя на структуру данных. Каждый класс имеет свое описание через файл, который включает в себя: 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'

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

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

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

1. Устройство для выполнения объектно-ориентированного кода, при этом упомянутое устройство содержит:
среду выполнения (355, 360, 1004), которая интерпретирует объявления (320, 1016) зависимостей производителя для методов в объектно-ориентированном коде, при этом объявления зависимостей производителя идентифицируют в среде выполнения набор из нуля или более производителей, причем производитель (110) является структурой, созданной средой выполнения, при этом каждый производитель создан из соответствующей комбинации конкретного экземпляра (108) класса и конкретного метода (104) этого класса и идентифицирует упомянутый конкретный экземпляр (108) и упомянутый конкретный метод (104), при этом выполнение производителя происходит методом, идентифицированным этим производителем, выполняемым в экземпляре, идентифицированном этим производителем, при этом среда выполнения включает в себя:
модуль (340, 365, 1040) автоматического формирования графов производителей, чтобы принимать обозначение интересующего производителя (325, 1025), добавлять интересующего производителя в качестве части графа производителей и автоматически формировать оставшуюся часть графа производителей через связывание, и создание экземпляров по мере необходимости, других производителей на основе объявлений зависимостей производителя для методов производителей, уже идентифицированных производителями на графе производителей; и
модуль (345, 370, 1070) выполнения графа производителей, чтобы выполнять производителей на графе производителей в порядке, указанном посредством графа производителей.

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

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

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

5. Устройство по п.1, в котором набор производителей, которые должны быть идентифицированы в среде выполнения посредством, по меньшей мере, одного из упомянутых объявлений (106) зависимостей производителя для данного метода, включает в себя, по меньшей мере, одного производителя (112) с выводом, который является прямым вводом в данный метод.

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

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

8. Устройство по п.7, в котором структура графа производителей дополнительно содержит:
структуру (382, 1080) маркировки инкрементного выполнения, чтобы помогать модулю выполнения графа производителей в отслеживании того, какие производители в текущей версии графа производителей должны быть повторно выполнены вследствие любых текущих модификаций.

9. Устройство по п.7, дополнительно содержащее:
журнал (396, 1047) регистрации подмены, соединенный с модулем вывода подмененных производителей и модулем выполнения графа производителей, чтобы собирать множество текущих модификаций вывода одного или более производителей в текущей версии графа производителей для обработки в пакетном режиме.

10. Устройство по п.7, в котором модуль вывода подмененных производителей также должен принимать индикаторы того, что должна быть отменена (1030) подмена одного или более подмененных выводов.

11. Устройство по п.1, в котором среда выполнения дополнительно содержит:
журнал (665) регистрации команд, соединенный с модулем автоматического формирования графов производителей, чтобы собирать несколько команд вместе для обработки в пакетном режиме.

12. Устройство по п.1, в котором объявления (106) зависимостей производителя являются частью определений (102) классов для классов в объектно-ориентированном коде (100).

13. Устройство по п.1, в котором любой метод может иметь одну из упомянутых объявлений зависимостей производителя.

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

15. Устройство по п.1, в котором конечные узлы графа производителей являются независимыми производителями (производитель 3).

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

17. Устройство по п.16, в котором среда выполнения дополнительно содержит:
модуль (1098) создания экземпляров, соединенный с упомянутой структурой отслеживания экземпляров, чтобы принимать обозначение и создавать экземпляр, в случае необходимости, текущего выбранного интересующего производителя;
структуру (1092) отслеживания классов, чтобы отслеживать ссылки на классы; и
модуль (1095) создания классов, соединенный со структурой отслеживания классов, чтобы загружать и анализировать определения классов.

18. Устройство по п.1, в котором среда выполнения дополнительно содержит:
модуль (1062) просмотра графов производителей, чтобы графически отображать представление текущего графа производителей.

19. Устройство по п.1, в котором среда выполнения дополнительно содержит:
модуль (1085) конфигурируемого интерактивного графического пользовательского интерфейса формата вывода производителя, чтобы графически отображать выводы и обеспечивать взаимодействие с графом производителей.

20. Устройство по любому из пп.1, 4, 5, 7-11 и 13-19, в котором модуль выполнения графа производителей включает в себя:
модуль (1075) динамических зависимостей, чтобы разрешать все динамические зависимости производителя, при этом каждое объявление зависимостей производителя может включать в себя динамическую зависимость производителя, причем динамические зависимости производителя инструктируют среде выполнения динамически выбирать набор из нуля или более производителей, которых объявление зависимостей производителя идентифицирует во время выполнения, и при этом динамический выбор может инструктировать выбор различных производителей для набора во время различного выполнения графа производителей.

21. Устройство по п.20, в котором динамические зависимости производителя включают в себя условные зависимости производителя, причем условные зависимости производителя являются зависимостями от производителей определения зависимостей (DDP6), которые сами зависят от вывода одного или более других производителей (S9).

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

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

24. Устройство по п.22, в котором некоторые из упомянутых подписок являются прикрепляющими подписками, при этом прикрепляющие подписки также идентифицируют характеристики (1425, 1430, 1435) для родительских производителей, и при этом прикрепляющие подписки инструктируют среде выполнения, для каждого найденного триггерного производителя (1475), создавать экземпляр родительского производителя (1480), удовлетворяющий идентифицированным характеристикам, и включать его в граф производителей как имеющего зависимость производителя от этого триггерного производителя.

25. Устройство по п.1, в котором некоторые из нуля или более производителей являются производителями (765) определения зависимостей, выполнение которых возвращает идентификационные данные зависимостей одного или более производителей от одного или более других производителей.

26. Устройство по п.25, в котором выполнение некоторых из производителей (772) определения зависимостей возвращает восходяще объявляемые зависимости.

27. Устройство по любому из пп.1, 21-26, в котором, по меньшей мере, некоторые из зависимостей, представленных посредством графа производителей, обозначаются как зависимости аргументов и зависимости (705) полей, при этом зависимости аргументов инструктируют среде выполнения преобразовывать выводы дочерних производителей (725) как входные параметры для родительских производителей (720), и при этом зависимости полей указывают использование полей экземпляров.

28. Устройство по любому из пп.1, 21-26, в котором, по меньшей мере, некоторые из зависимостей, представленных посредством графа производителей, обозначаются как зависимости (705) только для упорядочения, причем зависимости только для упорядочения требуют, чтобы выводы, которые должны быть предоставлены, если таковые имеются, от дочерних производителей (746) родительским производителям (720) осуществлялись через код в методе, идентифицированном дочерним производителем, чтобы записывать вывод в данный механизм, и код в методе, идентифицированном родительским производителем, чтобы считывать вывод из данного механизма.

29. Устройство по любому из пп.1, 21-26, в котором ключи (1190) методов используются для того, чтобы отличать методы, ключи (1120) экземпляров используются для того, чтобы отличать экземпляры, а ключи производителей используются для того, чтобы отличать производителей, при этом ключ производителя для каждого производителя основан, по меньшей мере, на ключе экземпляра и ключе метода для экземпляра и метода, идентифицированных этим производителем.

30. Устройство по п.29, в котором экземпляры являются экземплярами множества классов, при этом ключи (1090, 1110) классов используются для того, чтобы отличать упомянутое множество классов, и при этом ключ производителя для каждого производителя также основан на ключе класса для класса экземпляра, идентифицированного этим производителем.

31. Устройство по п.29, в котором ключ экземпляра, по меньшей мере, некоторых производителей хранит ссылку на экземпляр, идентифицированный этим производителем.

32. Устройство по п.1, в котором, по меньшей мере, некоторые из упомянутых объявлений зависимостей производителя включают в себя восходяще объявляемые зависимости (705).

33. Устройство по п.1, в котором, по меньшей мере, некоторые из упомянутых объявлений зависимостей производителя включают в себя нисходяще объявляемые зависимости (705).

34. Устройство по п.1, в котором, по меньшей мере, некоторые из упомянутых объявлений зависимостей производителя включают в себя как нисходяще, так и восходяще объявляемые зависимости (705).

35. Устройство по п.1, в котором упомянутый модуль автоматического формирования графов производителей активируется в ответ на команды (1025) создания производителя и в котором упомянутый модуль выполнения графа производителей активируется в ответ на команды (1035) выполнения.

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

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

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

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

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

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

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

43. Устройство по п.42, в котором выполнение некоторых из производителей определения зависимостей возвращает восходяще объявляемые зависимости.

44. Устройство по п.36, в котором, по меньшей мере, некоторые из объявлений зависимостей производителя включают в себя одно или более из зависимости аргументов и зависимости полей, при этом зависимости аргументов инструктируют среде выполнения преобразовывать выводы дочерних производителей как входные параметры в родительских производителей, и при этом зависимости полей указывают использование полей экземпляров.

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

46. Устройство по п.36, в котором ключ экземпляра, по меньшей мере, некоторых производителей хранит ссылку на экземпляр, идентифицированный этим производителем.

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

48. Способ выполнения объектно-ориентированного кода, при этом упомянутый способ содержит этапы, на которых:
создают экземпляр производителя с выводом, который является в настоящий момент интересующим (645), при этом объектно-ориентированный код включает в себя методы (104) и объявления (106) зависимостей производителя, при этом объявление зависимостей производителя для данного метода идентифицирует набор из нуля или более производителей, причем производитель (110) является структурой, созданной средой выполнения, при этом каждый производитель создан из соответствующей комбинации конкретного экземпляра (108) класса и конкретного метода (104) этого класса и идентифицирует упомянутый конкретный экземпляр (108) и упомянутый конкретный метод, при этом выполнение производителя происходит методом, идентифицированным этим производителем, выполняемым в экземпляре, идентифицированном этим производителем;
в ответ на упомянутое создание экземпляра добавляют интересующего производителя в качестве части текущего графа (645) производителей;
пытаются автоматически формировать оставшуюся часть текущего графа производителей через связывание, и создание экземпляра по мере необходимости, других производителей на основе объявлений зависимостей производителя методов, идентифицированных производителями, уже присутствующими на текущем графе производителей; и
выполняют производителей на текущем графе производителей, чтобы определять текущий вывод для упомянутого интересующего производителя (660).

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

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

51. Способ по п.48, в котором упомянутое выполнение включает в себя этап, на котором:
разрешают одну или более динамические зависимости (665) производителя, при этом каждое объявление зависимостей производителя может включать в себя динамическую зависимость производителя, причем динамические зависимости производителя инструктируют среде выполнения динамически выбирать набор из нуля или более производителей, которых объявление зависимостей производителя идентифицирует во время выполнения.

52. Способ по п.51, в котором динамические зависимости производителя включают в себя условные зависимости производителя, причем условные зависимости производителя являются зависимостями от производителей (DDP6) определения зависимостей, которые сами зависят от вывода одного или более других производителей (S9).

53. Способ по п.51 или 52, в котором динамические зависимости производителя включают в себя подписки, причем подписки идентифицируют критерии (1410), в соответствии с которыми производители сравниваются, чтобы определять то, являются ли они триггерными производителями, при этом подписки идентифицируют зависимости от триггерных производителей.

54. Способ по п.53, в котором некоторые из упомянутых подписок являются поглощающими подписками, причем поглощающие подписки инструктируют динамическое включение всех триггерных производителей (1460) в набор из нуля или более производителей, которых объявление зависимостей производителя идентифицирует во время выполнения.

55. Способ по п.54, в котором некоторые из упомянутых подписок являются прикрепляющими подписками, при этом прикрепляющие подписки также идентифицируют характеристики (1425, 1430, 1435) для родительских производителей, и при этом прикрепляющие подписки инструктируют для каждого найденного триггерного производителя (1475) создание экземпляра родительского производителя (1480), удовлетворяющего идентифицированным характеристикам, и включение его на текущий граф производителей как имеющего зависимость производителя от этого триггерного производителя.

56. Способ по любому из пп.48-52, 54, 55, в котором упомянутая попытка автоматически формировать дополнительно содержит этапы, на которых:
создают любые экземпляры производителей, которые еще не созданы (645, 1560); и
создают производителей, которые еще не созданы (645, 1625).

57. Способ любому из пп.48-52, 54, 55, в котором упомянутая попытка автоматически формировать дополнительно содержит этапы, на которых:
загружают любые классы экземпляров, идентифицированных производителями, которые еще не загружены (1540); и
анализируют определения классов для классов, которые еще не проанализированы (1550), включая операторы объявлений зависимостей производителя, содержащиеся в них.

58. Способ по п.57, в котором упомянутая попытка автоматически формировать включает в себя этап, на котором:
обнаруживают и встраивают в текущий граф производителей одного из производителей, для которых класс экземпляра, идентифицированный производителем, уже загружен и проанализирован до упомянутой попытки (1530), причем экземпляр, идентифицированный производителем, уже создан до упомянутой попытки (1520) и производитель уже создан до упомянутой попытки (1605).

59. Способ по любому из пп.48-52, 54, 55, 58, дополнительно содержащий этап, на котором:
графически отображают представление текущего графа производителей.

60. Способ по любому из пп.48-52, 54, 55, 58, дополнительно содержащий этап, на котором:
графически отображают выводы и обеспечивают взаимодействие с текущим графом производителей.

61. Способ по любому из пп.48-52, 54, 55, 58, дополнительно содержащий этапы, на которых:
сохраняют текущий вывод производителей текущего графа производителей (625);
подменяют текущий вывод одного или более производителей текущего графа производителей; и
повторно выполняют согласно текущему графу производителей и подмене и сохраненному текущему выводу тех из производителей, которые не затрагиваются прямо или косвенно посредством упомянутой подмены, только те из упомянутых производителей, которые затрагиваются, прямо или косвенно, посредством упомянутой подмены, чтобы определять их текущий вывод (660).

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

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

64. Способ по любому из пп.48-52, 54, 55, 58, 62, 63, в котором, по меньшей мере, некоторые из зависимостей, объявляемых посредством объявлений зависимостей производителя, обозначаются как зависимости аргументов и зависимости полей (705), причем зависимости аргументов инструктируют преобразование выводов дочерних производителей (725) как входных параметров в родительские производители (720), и причем зависимости полей указывают использование полей экземпляров.

65. Способ по любому из пп.48-52, 54, 55, 58, 62, 63, в котором, по меньшей мере, некоторые из зависимостей, объявляемых посредством объявлений зависимостей производителя, обозначаются как зависимости (705) только для упорядочения, причем зависимости только для упорядочения требуют, чтобы выводы, которые должны быть предоставлены, если таковые вообще имеются, от дочерних производителей (746) родительским производителям (720), осуществлялись через код в методе, идентифицированном дочерним производителем, чтобы записывать вывод в данный механизм, и код в методе, идентифицированном родительским производителем, чтобы считывать вывод из данного механизма.

66. Способ по любому из пп.48-52, 54, 55, 58, 62, 63, в котором ключи (1190) методов используются для того, чтобы отличать методы, ключи (1120) экземпляров используются для того, чтобы отличать экземпляры, а ключи производителей используются для того, чтобы отличать производителей, при этом ключ производителя для данного производителя основан, по меньшей мере, на ключе экземпляра и ключе метода экземпляра и метода, идентифицированных этим производителем.

67. Способ по п.66, в котором экземпляры являются экземплярами множества классов, при этом ключи (1090, 1110) классов используются для того, чтобы отличать упомянутое множество классов, и при этом ключ производителя для каждого производителя также основан на ключе класса для класса экземпляра, идентифицированного этим производителем.

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

69. Способ по п.48, в котором, по меньшей мере, некоторые из упомянутых объявлений зависимостей производителя включают в себя восходяще объявляемые зависимости (705).

70. Способ по любому из пп.48-52, 54, 55, 58, 62, 63, 67-69, в котором, по меньшей мере, некоторые из упомянутых объявлений зависимостей производителя включают в себя нисходяще объявляемые зависимости (705).

71. Способ по любому из пп.48-52, 54, 55, 58, 62, 63, 67-69, в котором, по меньшей мере, некоторые из упомянутых объявлений зависимостей производителя включают в себя как нисходяще, так и восходяще объявляемые зависимости (705).

72. Способ по любому из пп.48-52, 54, 55, 58, 62, 63, 67-69, в котором упомянутое создание экземпляра выполняется в ответ на команду (1025) создания производителя, а упомянутое выполнение выполняется в ответ на команду (1035) глобального выполнения.

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

74. Способ по п.73, в котором, по меньшей мере, один производитель является частью как целевого подграфа, так и одного из решающих подграфов.

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

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

77. Способ по п.73, в котором, по меньшей мере, один из решающих подграфов возвращает подписку.

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

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

80. Способ по п.73, в котором, по меньшей мере, один из решающих подграфов возвращает восходяще объявляемую зависимость производителя.

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

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

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

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

85. Способ по п.73, дополнительно содержащий этап, на котором:
графически отображают представление графа производителей.

86. Способ по п.73, дополнительно содержащий этап, на котором:
графически отображают выводы и обеспечивают взаимодействие с графом производителей.

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

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

89. Устройство по п.88, в котором, по меньшей мере, один производитель является частью как целевого подграфа, так и одного из решающих подграфов.

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

91. Устройство по п.88, в котором целевой подграф имеет корень, который является стандартным производителем.

92. Устройство по п.88, в котором, по меньшей мере, один из решающих подграфов возвращает подписку.

93. Устройство по п.92, в котором подписка является поглощающей подпиской, которая указывает критерии поглощающей подписки для триггерных производителей.

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

95. Устройство по п.88, в котором, по меньшей мере, один из множества решающих подграфов возвращает восходяще объявляемую зависимость производителя.

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

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

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

99. Устройство по п.97, в котором ключ экземпляра, по меньшей мере, некоторых производителей хранит ссылку на экземпляр, идентифицированный этим производителем.

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

101. Устройство по п.88, в котором среда выполнения дополнительно содержит:
модуль конфигурируемого интерактивного графического пользовательского интерфейса формата вывода производителя, чтобы графически отображать выводы и обеспечивать взаимодействие с графом производителей.

102. Устройство по п.88, в котором упомянутый модуль автоматического формирования графов производителей активируется в ответ на команды создания производителя, и в котором упомянутый модуль выполнения графа производителей активируется в ответ на команды выполнения.

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

104. Машиночитаемый носитель хранения по п.103, в котором:
четвертый производитель имеет следующую подписную зависимость от триггерного производителя:
четвертый метод из упомянутых наборов методов, при этом упомянутый четвертый производитель основан на упомянутом четвертом методе,
пятый метод из упомянутых наборов методов, который имеет код, который указывает набор критериев подписки для триггерных производителей, при этом подписной производитель основан на упомянутом пятом методе, и
шестой метод из упомянутых наборов методов, при этом упомянутый триггерный производитель основан на упомянутом шестом методе, и упомянутая подписная зависимость создается, потому что упомянутый триггерный производитель удовлетворяет упомянутому набору критериев подписки.

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

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

107. Машиночитаемый носитель хранения по п.103, в котором, по меньшей мере, одно из упомянутых объявлений зависимостей производителя включает в себя строго ограниченную зависимость аргументов.

108. Машиночитаемый носитель хранения по п.103, в котором, по меньшей мере, одна из упомянутых объявлений зависимостей производителя включает в себя строго ограниченную зависимость полей.

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

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

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

112. Машиночитаемый носитель хранения по п.110, в котором ключ экземпляра, по меньшей мере, некоторых производителей хранит ссылку на экземпляр, идентифицированный этим производителем.

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

114. Машиночитаемый носитель хранения по п.113, в котором, по меньшей мере, некоторые из упомянутых объявлений зависимостей производителя включают в себя динамическую зависимость производителя, при этом динамические зависимости производителя инструктируют динамический выбор набора из нуля или более производителе во время выполнения.

115. Машиночитаемый носитель хранения по п.114, в котором динамические зависимости производителя включают в себя условные зависимости производителя, причем условные зависимости производителя являются зависимостями от производителей определения зависимостей, которые сами зависят от вывода одного или более других производителей.

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

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

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

119. Машиночитаемый носитель хранения по п.113, в котором, по меньшей мере, некоторые из зависимостей, объявляемых посредством объявлений зависимостей производителя, обозначаются как зависимости аргументов и зависимости полей, причем зависимости аргументов инструктируют преобразование выводов дочерних производителей как входных параметров в родительские производители, и причем зависимости полей указывают использование полей экземпляров.

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

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

122. Машиночитаемый носитель хранения по п.120, в котором ключ экземпляра, по меньшей мере, некоторых производителей хранит ссылку на экземпляр, идентифицированный этим производителем.

123. Машиночитаемый носитель хранения по п.113, в котором, по меньшей мере, некоторые из упомянутых объявлений зависимостей производителя включают в себя восходяще объявляемые зависимости.

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

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

126. Машиночитаемый носитель хранения по п.124, в котором структура графа производителей представляет прямые зависимости между вводом и выводом производителей друг от друга от интересующего производителя для тех из производителей, которые являются конечными узлами графа производителей.

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

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

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

130. Машиночитаемый носитель хранения по п.124, дополнительно хранящий:
набор определений классов, написанных в объектно-ориентированном коде для набора классов, при этом каждое из объявлений зависимостей производителя включает в себя, оператор объявления зависимостей производителя, находящийся рядом с одним из методов, для которых он предназначен.

131. Машиночитаемый носитель хранения по п.124, в котором ключ экземпляра, по меньшей мере, некоторых производителей хранит ссылку на экземпляр производителя.

132. Машиночитаемый носитель хранения по п.125, в котором каждый ключ производителя также основан, по меньшей мере, на ключе класса, который идентифицирует класс экземпляра производителя.

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

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

135. Машиночитаемый носитель хранения по п.134, в котором клиентский код также включает в себя:
команды отмены подмены вывода производителя, каждая из которых имеет ключ производителя для одного из производителей, который подменен, и каждая из которых побуждает среду выполнения для объектно-ориентированного кода отменять подмену вывода этого производителя.

136. Машиночитаемый носитель хранения по п.134, в котором команда создания экземпляра производителя является командой создания производителя и в котором команды подмены вывода производителя являются командами задания параметров.

137. Машиночитаемый носитель хранения по п.134, в котором причинно-следственная зависимость команды создания экземпляра производителя и команд подмены вывода производителя является косвенной через журнал регистрации, хранимый посредством среды выполнения для объектно-ориентированного кода.

138. Машиночитаемый носитель хранения по п.134, в котором первая из команд выполнения инструктирует начальное выполнение, а каждая последующая из команд выполнения инструктирует инкрементное выполнение.

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

140. Машиночитаемый носитель хранения по п.134, в котором за каждым набором из одной или более из команд подмены вывода производителя следует одна из команд выполнения.

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

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

143. Машиночитаемый носитель хранения по п.134, в котором ключ экземпляра, по меньшей мере, некоторых производителей хранит ссылку на экземпляр, идентифицированный этим производителем.

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

145. Машиночитаемый носитель хранения по п.134, в котором упомянутый объектно-ориентированный исходный код также включает в себя определения классов, при этом упомянутые определения классов включают в себя бизнес-логику, выраженную в методах с объявлениями зависимостей производителя.

146. Машиночитаемый носитель хранения по п.145, в котором объявления зависимостей производителя используются для того, чтобы задавать связи между производителями в ходе определения классов, которые включают в себя бизнес-логику, а не после того как экземпляры этих классов созданы.

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

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

149. Способ по п.147, в котором упомянутое заполнение дополнительно содержит этап, на котором
принимают индикатор относительно выбора набора из одного или более экземпляров.

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

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

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

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

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

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

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

157. Способ по п.147, в котором, по меньшей мере, одно из объявлений зависимостей производителя включает в себя динамическую зависимость производителя, при этом динамические зависимости производителя побуждают динамический выбор набора из нуля или более производителей, что объявление зависимости производителя идентифицирует во время выполнения.

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

159. Способ по п.157, в котором динамический производитель возвращает подписку.

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

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

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

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

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

Изобретение относится к вычислительной технике. .

Интерактивное управление доступом к услугам и возможностями мобильного устройства // 2441270

Изобретение относится к средствам управления доступом к услугам и возможностями мобильного устройства. .

Система и способ для анализа взаимодействия свет-материал на основе спектрального свертывания // 2440603

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

Модель фазирования прикладной среды // 2439664

Изобретение относится к области выполнения программного обеспечения. .

Инфраструктура графоориентированного программирования на основе производителей с поддержкой сценариев // 2438161

Изобретение относится к области выполнения кода в среде выполнения. .

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

Изобретение относится к способам дистанционного удаления программ с использованием беспроводной сети. .

Адаптивное управление энергопотреблением // 2436144

Изобретение относится к вычислительной технике. .

Способ и программа обработки информации // 2435203

Изобретение относится к способам установки и запуска программ. .

Устройство передачи данных для эмуляции поведения навигационного устройства // 2435202

Изобретение относится к информационным технологиям, в частности к области мобильной навигации. .

Параллелизация и инструментальные средства в инфраструктуре графоориентированного программирования на основе производителей // 2435201

Изобретение относится к области программирования и выполнения кода в среде выполнения. .

Запуск гипервизора в запущенной операционной системе // 2446447

Изобретение относится к области вычислительной техники, а более точно к способу запуска гипервизора в компьютерной системе

Система и способ для модификации хирургических операций с использованием графического интерфейса с перетаскиванием // 2454207

Изобретение относится к медицинской технике, а именно к системам и способам для модификации хирургических операций

Прогрессивная начальная загрузка для беспроводного устройства // 2456663

Изобретение относится к области начальной загрузки беспроводного устройства при включении питания

Программируемый мультимедийный контроллер с программируемыми функциями // 2460119

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

Унифицированное предоставление физических и виртуальных образов // 2462749

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

Динамическое преобразование интерфейса командной строки (cli) для сгруппированных объектов программного обеспечения // 2463646

Изобретение относится к средствам преобразования интерфейса для определенного программного обеспечения

Система обработки инструкций в режиме реального времени // 2465634

Изобретение относится к архитектуре обработки с использованием вычислительных средств

Способ и система для создания ит-ориентированных серверных сетевых приложений // 2466450

Изобретение относится к способу управления объектами приложений

Способ децентрализации программы для эвм // 2467379

Изобретение относится к технике организации распределенных вычислений и защите информации

Устройство и способы для управления памятью, связанной с виджетами // 2468419

Изобретение относится к вычислительной технике