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

Формула изобретения

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

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

в ответ на упомянутое создание экземпляра добавляют интересующего производителя в качестве части графа производителей;

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

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

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

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

идентифицируют набор готовых производителей среди производителей на графе производителей;

определяют режим выполнения каждого производителя из набора готовых производителей;

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

3. Способ по п.2, в котором режим выполнения является одним из режима локального выполнения, режима многопроцессорной обработки и режима многопоточной обработки.

4. Способ по п.2, дополнительно содержащий этапы, на которых:

создают задачу для каждого производителя в наборе готовых

производителей; и

инструктируют выполнение задачи в режиме выполнения соответствующего производителя.

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

6. Способ по п.2, в котором определение режима выполнения каждого производителя набора готовых производителей содержит этапы, на которых:

проверяют настройку режима выполнения метода, идентифицированного соответствующим производителем;

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

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

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

7. Способ по п.1, дополнительно содержащий этапы, на которых:

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

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

производителей по принципу "производитель-за-производителем".

8. Способ по п.7, в котором получение показателей дополнительно содержит этап, на котором:

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

9. Способ по п.8, в котором получение показателей дополнительно содержит этап, на котором:

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

выполняют множество производителей локально;

измеряют время локального выполнения множества производителей;

отправляют задание в решетку процессоров, при этом решетка процессоров выполняет множество производителей, по существу, параллельно;

измеряют полное время выполнения задания;

сравнивают время локального выполнения с полным временем удаленного выполнения; и

измеряют размер входных потоков и размер выходных потоков по принципу "производитель-за-производителем".

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

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

в ответ на упомянутое создание экземпляра добавляют интересующего производителя в качестве части графа производителей;

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

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

11. Способ по п.10, в котором снабжение инструментальными средствами прикладной программы содержит этап, на котором:

измеряют время выполнения прикладной программы по принципу "производитель-за-производителем".

12. Способ по п.10, в котором снабжение инструментальными средствами прикладной программы дополнительно содержит этапы, на которых:

отправляют задание в решетку процессоров, при этом решетка процессоров выполняет множество производителей задания практически параллельно;

измеряют полное время выполнения задания; и

измеряют размер входных потоков и размер выходных потоков по принципу "производитель-за-производителем".

13. Способ по п.12, в котором снабжение инструментальными средствами прикладной программы дополнительно содержит этап, на котором:

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

выполняют множество производителей задания локально; и измеряют время локального выполнения множества производителей.

14. Способ по п.13, в котором выполнение сравнительного тестирования дополнительно содержит этапы, на которых:

сравнивают время локального выполнения с полным временем удаленного выполнения; и

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

15. Устройство для обеспечения параллелизации при выполнении прикладной программы, написанной в объектно-ориентированном коде, содержащее:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

23. Устройство по п.15, в котором среда выполнения дополнительно содержит:

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

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

24. Устройство по п.15, в котором среда выполнения дополнительно содержит:

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

25. Устройство по п.15, в котором среда выполнения дополнительно содержит:

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

26. Устройство для обеспечения инструментальных средств при выполнении прикладной программы, написанной в объектно-ориентированном коде, содержащее:

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

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

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

модуль получения показателей, выполненный с возможностью получать показатели, связанные с выполнением множества производителей по принципу "производитель-за-производителем", если запрошены инструментальные средства.

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

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

множество определений классов, каждое из которых включает в себя:

набор из одного или более полей,

набор из одного или более методов,

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

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

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

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

31. Машиночитаемый носитель по п.28, в котором объектно-ориентированный исходный код дополнительно включает в себя:

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

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

33. Машиночитаемый носитель по п.31, в котором режим выполнения является одним из режима локального выполнения, режима многопроцессорной обработки и режима многопоточной обработки.

34. Машиночитаемый носитель по п.31, в котором одно или более из множества определений классов дополнительно включает в себя:

одну или более настроек режима выполнения, предоставляемых в примечании.

35. Машиночитаемый носитель по п.28, в котором объектно-ориентированный исходный код дополнительно включает в себя:

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

36. Машиночитаемый носитель по п.28, в котором объектно-ориентированный исходный код дополнительно включает в себя:

команду настройки подмены режима выполнения производителя, чтобы подменять режим выполнения по принципу "производитель-за-производителем".

37. Машиночитаемый носитель по п.28, в котором объектно-ориентированный исходный код дополнительно включает в себя:

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

Описание изобретения к патенту

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выполнение программ и параллелизация

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

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

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

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

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

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

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

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

Программные инструментальные средства

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

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

Другая традиционная методика в инструментальных средствах состоит в том, чтобы использовать данные промежуточного представления (IR), формируемые из исходного кода прикладной программы. В частности, компилятор формирует данные IR из исходного кода. Модуль инструментальных средств кода работает с данными IR, чтобы составлять дерево IR и добавлять инструментальные средства к данным IR на основе дерева IR. Затем компилятор заканчивает компиляцию посредством преобразования данных IR с инструментальными средствами в объектный код. Экземпляр класса может быть снабжен инструментальными средствами, используя библиотеку инструментальных средств (в дальнейшем, DLL инструментальных средств). Модуль среды выполнения виртуальной машины (VM) может запускать снабженный инструментальными средствами экземпляр класса. Предусмотрены объявления имен и параметров методов в байтовом коде экземпляра класса. Специальный указатель указывает то, что исполняемые части, соответствующие объявленным методам, находятся в некоторых блоках собственного кода, отдельных от модуля среды выполнения VM. Например, снабженный инструментальными средствами байтовый код Java VM может отслеживаться в ходе выполнения посредством процесса мониторинга и библиотеки мониторинга (т.е. DLL мониторинга).

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

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

фиг.1D иллюстрирует некоторые дополнительные примерные комбинации взаимосвязей родительских производителей 114 и дочерних производителей 112 с производителем 110A согласно одному варианту осуществления изобретения;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

фиг.7D иллюстрирует псевдокод объявления зависимостей производителя для метода с использованием несокращенной зависимости согласно одному варианту осуществления изобретения;

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

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

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

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

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

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

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

фиг.8C иллюстрирует примерный снимок экрана и использование свободного выбора ячеек с помощью конфигурируемого интерактивного модуля 840 графического пользовательского интерфейса формата вывода производителя согласно одному варианту осуществления изобретения;

фиг.8D иллюстрирует другой примерный снимок экрана и использование свободного выбора ячеек с помощью конфигурируемого интерактивного модуля 840 графического пользовательского интерфейса формата вывода производителя согласно одному варианту осуществления изобретения;

фиг.8E иллюстрирует примерный снимок экрана и использование создания таблицы с помощью конфигурируемого интерактивного модуля 840 графического пользовательского интерфейса формата вывода производителя согласно одному варианту осуществления изобретения;

фиг.8F иллюстрирует другой примерный снимок экрана и использование создания таблицы с помощью конфигурируемого интерактивного модуля 840 графического пользовательского интерфейса формата вывода производителя согласно одному варианту осуществления изобретения;

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

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

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

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

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

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

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

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

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

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

фиг.11G - это блок-схема примера основанной на производителе конфигурируемой структуры 1049 решений по фиг.10 согласно одному варианту осуществления изобретения;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обзор

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

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

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

Фиг.1A - это блок-схема, иллюстрирующая взаимосвязь объявления зависимостей производителя для метода класса в объектно-ориентированном исходном коде с производителем, который включает в себя класс, данный экземпляр этого класса и метод этого класса, согласно одному варианту осуществления изобретения. На фиг.1A показан объектно-ориентированный исходный код 100, включающий в себя класс 102, который, в свою очередь, включает в себя метод 104, настройки 105 режима выполнения и объявление 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) автоматически формирует (обнаруживает, строит и необязательно разрешает) набор из одного или более графов, которые могут быть многоуровневыми и могут иметь различные формы (к примеру, цепочку, дерево), из данного набора производителей, обозначенных как представляющие интерес нижележащим исходным производителям, на основе объявлений 106 зависимостей производителя; и 2) упорядочивает выполнение производителей из набора графов, чтобы формировать вывод(ы) данного набора производителей, обозначенных как представляющие интерес. Таким образом, среда выполнения использует объявления 106 зависимостей производителя для того, чтобы определять, какие методы с какими аргументами выполнять, на каких экземплярах и когда в целях синхронизации.

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

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

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

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

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

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

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

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

Использование ключей предоставляет множество признаков, в том числе: 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 выполнения графа производителей включает в себя модуль 3451 параллелизации, модуль 3453 многопроцессорной обработки, модуль 3455 многопоточной обработки и модуль 3457 локального выполнения. Модуль 3451 параллелизации может определять режим выполнения производителя и отправлять производителя в одно из модуля 3453 многопроцессорной обработки, модуля 3455 многопоточной обработки и модуля 3457 локального выполнения, чтобы быть выполняемым в определенном режиме выполнения. Параллелизация может поддерживаться посредством отдельного режима выполнения. Например, параллельное выполнение производителей может быть осуществлено посредством модуля 3453 многопроцессорной обработки с помощью многопроцессорной обработки. Альтернативно, параллельное выполнение производителей может быть осуществлено посредством модуля 3455 многопоточной обработки с помощью многопоточной обработки. Кроме этого, параллелизация может поддерживаться посредством комбинации режимов выполнения. Другими словами, производители могут выполняться параллельно с использованием различных режимов выполнения. Например, два производителя могут выполняться параллельно посредством отправки одного производителя в модуль 3455 многопоточной обработки и другого производителя в модуль 3457 локального выполнения. Следует принимать во внимание, что другие комбинации режимов выполнения могут использоваться для того, чтобы реализовать параллелизацию.

Модуль 345 выполнения графа производителей кэширует текущие выводы производителей в структуре 380 графов производителей, как проиллюстрировано посредством кэширования 384 выводов производителя. Кэширование выводов производителя для графа производителей в ходе выполнения предоставляет возможность синхронизации. Например, подходящее время для того, чтобы выполнять родительский производитель, который зависит от нескольких дочерних производителей, - это время после того, как все несколько дочерних производителей выполнены; другими словами, излишне (и в некоторых случаях невозможно) выполнять родительский производитель каждый раз, когда один из его дочерних производителей завершил выполнение. Кэширование выводов производителя предоставляет возможность не только откладывания выполнения родительского производителя до тех пор, пока все его дочерние производители не выполнены, оно также предоставляет возможность определения подходящего времени для выполнения родительского производителя - когда все дочерние производители выполнены, и их выводы кэшированы. Таким образом, среда выполнения принимает это решение синхронизации для программиста посредством проверки доступности необходимых выводов в кэшировании 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 направляется по данным в том смысле, что данные протекают от одного производителя к другому производителю вверх по графу.

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

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

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

Фиг.3B - это блок-схема, иллюстрирующая среду выполнения со средствами поддержки графоориентированного программирования на основе производителей, которая также поддерживает инкрементное выполнение и выводы подмененных производителей согласно одному варианту осуществления изобретения. Следует понимать, что инкрементное выполнение и выводы подмененных производителей являются независимыми необязательными признаками, и, таким образом, различные варианты осуществления изобретения могут реализовать один из них или оба. Хотя не проиллюстрировано явно на чертеже 3B, следует принимать во внимание, что модули 3451 параллелизации, модуль 3453 многопроцессорной обработки, модуль 3455 многопоточной обработки и модуль 3457 локального выполнения на фиг.3A могут быть включены в модуль 370 выполнения графа производителей на фиг.3B, чтобы давать возможность модулю 370 выполнения графа производителей на фиг.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 выводов производителя. Производители, которые готовы к выполнению, могут быть выполнены параллельно. Другими словами, параллелизация также может быть автоматизирована. Таким образом, отдельный исходный код не требуется для того, чтобы определять или указывать, какие производители должны быть выполнены параллельно. Помимо этого, данное кэширование 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) вызываемую часть (называемую внешним источником данных). Если производитель считывает данные непосредственно из внешнего источника данных, он может считывать данные только тогда, когда производитель создается, считывать данные только тогда, когда инструктировано выполнять так (обновление вручную) или подписываться на них. В случае обновления вручную и подписки изменения во внешнем источнике данных должны приводить к активации метода задания производителя и модификации вывода производителя (обрабатываемой так же, как подмененный производитель).

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

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

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

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

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

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

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

Динамическая зависимость производителя - это зависимость производителя, которая может изменяться во время выполнения. Следует понимать, что критерии для разрешения зависимости производителя присутствуют в исходном коде, и, таким образом, производители, для которых может быть разрешена зависимость производителя, ограничены. Со ссылкой на фиг.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 является независимым производителем. Отметим, что производитель 7A может быть выполнен отдельно или выполнен параллельно с производителем 6, или выполнен параллельно с производителем 4, выполнен параллельно с производителем 3 или выполнен параллельно с любой комбинацией производителей 3, 4 и 6. Такое параллельное выполнение разрешено, поскольку производитель 7A является независимым от производителей 3, 4 и 6.

Фиг.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). В некоторых вариантах осуществления параллелизация может быть реализована посредством выполнения производителей на каждом уровне параллельно. Выполнение производителей может начинаться с производителей на нижнем уровне, таком как уровень 5 на фиг.5C, и затем двигается вверх уровень за уровнем. Перед началом выполнения производителей на уровне среда выполнения может ждать до тех пор, пока все производители на предыдущем нижнем уровне не готовы, т.е. выводы производителей на предыдущем нижнем уровне не возвращены. При рассмотрении ветвления от производителя 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 для зависимостей полей 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 объявления зависимостей производителя, ассоциативно связанный с зависимостью аргументов 1. В ходе выполнения среда выполнения осуществляет доступ и выполняет код 715 объявления зависимостей производителя в ответ на зависимость аргументов 1 из оператора 705 объявления зависимостей производителя. Выполнение кода 715 объявления зависимостей производителя возвращает производителя 725 как зависимость производителя для зависимости аргументов 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 и 1082; тогда как сплошная линия со стрелками представляет прямую причинную взаимосвязь от этапа 1035 логического потока выполнения клиента 1002 среды выполнения к этапу 1070 среды выполнения со средствами поддержки графоориентированного программирования на основе производителей 1004, пунктирные линии со стрелками иллюстрируют причинную взаимосвязь от этапов 1010, 1020, 1025 и 1030 клиента 1002 среды выполнения к этапам 1095, 1098, 1040 и 1045 среды выполнения со средствами поддержки графоориентированного программирования на основе производителей 1004. В зависимости от варианта осуществления изобретения эти последние причинные взаимосвязи могут быть прямыми или косвенными. Например, аналогично фиг.6, необязательная косвенная причинно-следственная зависимость через использование журнала регистрации команд (не показан) и/или журнала 1047 регистрации подмены может использоваться. Дополнительные этапы 1095 и 1098 являются пунктирными, поскольку они необязательно могут быть частью другого этапа в зависимости от варианта осуществления изобретения (к примеру, этап 1095 может быть частью этапа 1098; этап 1090 может быть частью этапа 1040; этапы 1095 и 1090 могут быть частью этапа 1040). Аналогично, этап 1045 является пунктирным, поскольку он необязательно может быть частью другого этапа в зависимости от варианта осуществления изобретения (к примеру, этап 1045 может быть частью этапа 1070). Аналогично, этап 1049 необязательно может быть частью другого этапа в зависимости от варианта осуществления изобретения (к примеру, этап 1049 может быть частью этапа 1040). В некоторых вариантах осуществления среда 1004 выполнения включает в себя модуль 1082 получения показателей. Модуль 1082 получения показателей необязательно может быть частью этапа 1070.

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

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

Клиент 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) осуществляет доступ к структуре 1058 отслеживания методов с помощью ключа метода, чтобы осуществлять доступ к соответствующему оператору объявления зависимостей производителя. Создание экземпляра производителей, обозначенных посредством команд создания экземпляра производителя, с помощью ключей 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 среды выполнения также включает в себя команды 1036 выбора режима выполнения согласно некоторым вариантам осуществления изобретения. Пользователь может использовать команды 1036 выбора режима выполнения для того, чтобы изменять настройку(ки) режима выполнения посредством изменения структуры 1048 настройки среды выполнения, основанной на производителе конфигурируемой структуры 1049 решений и/или структуры 1060 графа производителей. В одном варианте осуществления команды 1036 выбора режима выполнения изменяют основанную на производителе конфигурируемую структуру 1049 решений, чтобы модифицировать настройки режима выполнения конкретного класса, конкретного экземпляра, конкретного метода или любой комбинации вышеупомянутого. Например, первая команда выбора режима выполнения может изменять настройку режима выполнения всех методов конкретного класса на первый режим выполнения, вторая команда выбора режима выполнения может изменять настройку режима выполнения конкретного экземпляра конкретного класса, третья команда выбора режима выполнения может изменять настройку режима выполнения конкретного метода, четвертая команда выбора режима выполнения может изменять настройку режима выполнения конкретного метода и конкретного экземпляра и т.д. Альтернативно, пользователь может использовать команды 1036 выбора режима выполнения для того, чтобы изменять настройку(и) режима выполнения по принципу "производитель-за-производителем" посредством изменения структуры 1060 графа производителей. Поскольку каждый производитель в структуре 1060 графа производителей имеет настройку режима выполнения производителя, команды 1036 выбора режима выполнения могут предоставлять ключ производителя, идентифицирующий конкретного производителя и требуемую настройку режима выполнения для конкретного производителя, чтобы инструктировать среде 1004 выполнения изменять настройку режима выполнения для конкретного производителя на требуемую настройку режима выполнения.

Клиент 1002 среды выполнения также включает в себя команды 1035 глобального выполнения. Модуль 1070 выполнения графа производителей среды 1004 выполнения выполняет граф(ы) производителей. Модуль 1070 выполнения производителя может выполнять каждый производитель на графе(ах) производителей на основе соответствующего режима выполнения производителя из основанной на производителе структуры 1049 конфигурирования. В некоторых вариантах осуществления модуль 1070 выполнения производителя может подменять режим выполнения предварительно определенного производителя из основанной на производителе структуры 1049 конфигурирования. Например, если режим выполнения из основанной на производителе структуры 1049 конфигурирования не поддерживается посредством среды 1004 выполнения, то модуль 1070 выполнения производителя может подменять такой режим выполнения.

В некоторых вариантах осуществления среда 1004 выполнения поддерживает три режима выполнения, а именно многопроцессорную обработку, многопоточную обработку и локальное выполнение. Таким образом, модуль 1070 выполнения производителя включает в себя модуль 1076 параллелизации, модуль 1077 многопроцессорной обработки, модуль 1078 многопоточной обработки и модуль 1079 локального выполнения. Для каждого производителя модуль 1040 автоматического формирования графа производителей может находить соответствующий режим выполнения из основанной на производителе конфигурируемой структуры 1049 решений и может задавать настройку режима выполнения производителя соответствующим образом в структуре 1060 графа производителей, если соответствующий режим выполнения не подменяется настройкой среды выполнения в структуре 1048 настройки среды выполнения. На основе настройки режима выполнения производителя в структуре 1060 графа производителей модуль 1076 параллелизации может отправлять производителя в соответствующей один из модуля 1077 многопроцессорной обработки, модуля 1078 многопоточной обработки и модуля 1079 локального выполнения. Затем может быть создан экземпляр задачи для производителя в модуле 1077 многопроцессорной обработки, модуле 1078 многопоточной обработки и/или модуле 1079 локального выполнения. Задача - это логически высокоуровневый дискретный независимый участок вычислительной работы. Задача типично выполняется посредством процессора как программа.

В некоторых вариантах осуществления, если режимом выполнения является многопроцессорная обработка, то модуль 1076 параллелизации может отправлять производителя в модуль 1077 многопроцессорной обработки. Модуль 1077 многопроцессорной обработки может преобразовывать в последовательную форму задачу, соответствующую производителю, а также вводам в производитель, и добавлять преобразованную в последовательную форму задачу и вводы на задание. Когда задачи, соответствующие всем готовым быть выполняемыми производителям, имеющим режим выполнения в многопроцессорной обработке, добавлены в задание, модуль 1077 многопроцессорной обработки может отправлять задание в диспетчер 1081 решетки, чтобы перенаправить в решетку процессоров. После этого некоторые или все процессоры в решетке могут удаленно выполнять задачи в задании. Если режимом выполнения является многопоточная обработка, то модуль 1076 параллелизации может отправлять производителя в модуль 1078 многопоточной обработки. Модуль 1078 многопоточной обработки может инициировать механизм организации пула потоков и подавать задачу, соответствующую производителю, в доступный поток, который должен быть выполнен. Если режимом выполнения является локальное выполнение, то модуль 1076 параллелизации может отправлять производителя в локальный модуль 1079. Локальный модуль 1079 затем может выполнять задачу в рамках текущего потока среды выполнения.

В некоторых вариантах осуществления модуль 1076 параллелизации может отправлять производителя в предварительно определенный один из модуля 1077 многопроцессорной обработки, модуля 1078 многопоточной обработки и модуля 1079 локального выполнения по умолчанию, если режим выполнения не указан для производителя. С другой стороны, если определение 1010 класса производителя включает в себя настройку 1015 режима выполнения для производителя, модуль 1076 параллелизации может отправлять производителя согласно настройке 1015 режима выполнения, если только настройка 1015 режима выполнения не подменена. Настройка 1015 режима выполнения может быть подменена различными способами. В одном варианте осуществления команды 1036 выбора режима выполнения изменяют настройки режима выполнения в основанной на производителе конфигурируемой структуре 1049 решений на основе класса, на основе метода, на основе экземпляра или любой комбинации вышеупомянутого, чтобы подменять настройку 1015 режима выполнения. В одном варианте осуществления команды 1036 выбора режима выполнения изменяют настройки режима выполнения по принципу "производитель-за-производителем" в структуре 1060 графа производителей, чтобы подменять настройку режима выполнения, определенную с помощью основанной на производителе конфигурируемой структуры 1049 решений. В одном варианте осуществления команды 1036 выбора режима выполнения изменяют настройки режима выполнения на глобальном уровне среды выполнения в структуре 1048 настройки среды выполнения, чтобы подменять настройки режима выполнения в структуре 1060 графа производителей.

По сути, модуль 1070 выполнения графа производителей модифицирует кэширование 1097 выводов производителя (в случае производителей свойств и производителей методов), использует маркировку 1080 инкрементного выполнения (если присутствует) и модифицирует данные экземпляров 1052 (в случае методов свойств). В некоторых вариантах осуществления модуль 1082 получения показателей может получать показатели в ходе выполнения производителей. Полученные показатели могут быть сохранены в показателях 1083 в структуре 1060 графа(ов) производителей. Отметим, что показатели могут быть получены на основе производителя, и поскольку производитель включает в себя уникальную комбинацию класса, метода и экземпляра, полученные показатели могут быть на основе метода-экземпляра-класса. Кроме этого, полученные показатели могут быть на основе задачи и/или на основе задания.

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

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

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

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

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

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

Фиг.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 маркировки инкрементного выполнения, чтобы сохранять маркировки инкрементного выполнения, как ранее описано.

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

Дополнительно, фиг.11C включает в себя столбец 1175 показателей производителя, чтобы сохранять показатели каждого производителя в структуре 1060 графа производителей. Показатели производителя получаются по принципу "производитель-за-производителем" с использованием модуля 1082 получения показателей. Подробности некоторых вариантов осуществления процесса, чтобы получать показатели, поясняются ниже.

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

Фиг.11E - это блок-схема примера локальной таблицы последовательной формы согласно одному варианту осуществления изобретения. Локальная таблица последовательной формы на фиг.11E включает в себя столбец 1112 идентификаторов последовательной формы, столбец 1113 ключей входных производителей, столбец 1114 ключей базисных классов и ключей экземпляров, последовательную форму 1116, размер 1117 последовательной формы и время 1118 преобразования в последовательную форму. В некоторых вариантах осуществления идентификатор последовательной формы, ключ входного производителя, ключ базисного экземпляра и последовательная форма используются для того, чтобы реализовать параллелизацию посредством среды 1004 выполнения. Подробности реализации поясняются ниже. В некоторых вариантах осуществления среда 1004 выполнения реализует инструментальные средства, чтобы получать показатели на основе производителя. Таким образом, среда 1004 выполнения может сохранять размер последовательной формы и время преобразования в последовательную форму в столбцах, указанных посредством пунктирных линий в локальной таблице последовательной формы. Подробности инструментальных средств поясняются ниже.

Фиг.11F - это блок-схема примера структуры 1048 настройки среды выполнения по фиг.10 согласно одному варианту осуществления изобретения. Таблица включает в себя столбец 1121 начального режима выполнения и столбец 1123 конечного режима выполнения. Если режим выполнения не подменяется на глобальном уровне среды выполнения, конечный режим выполнения является таким же, как первоначальный режим выполнения. С другой стороны, если режим выполнения подменяется на глобальном уровне среды выполнения, конечный режим выполнения отличается от начального режима выполнения. Например, если среда 1004 выполнения не поддерживает многопроцессорную обработку, то многопроцессорная обработка может быть подменена на глобальном уровне среды выполнения посредством назначения локального выполнения в качестве конечного режима выполнения в многопроцессорной обработке.

Фиг.11G - это блок-схема примера основанной на производителе конфигурируемой структуры 1049 решений на фиг.10. Таблица включает в себя столбец 1182 ключей классов, столбец 1184 ключей методов, столбец 1186 ключей экземпляров, столбец 1188 настроек режима выполнения. Команды 1036 выбора режима выполнения могут модифицировать настройку режима выполнения в основанной на производителе конфигурируемой структуре решений на основе класса, метода, экземпляра или любой комбинации вышеупомянутого. Таким образом, одно или более из столбца 1182 ключей классов, столбца 1184 ключей методов и столбца 1186 ключей экземпляров могут быть пустыми в конкретной строке согласно одному варианту осуществления изобретения.

Удаленное вычисление

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

Фиг.12A - это блок-схема, иллюстрирующая дополнительные детали фиг.10, чтобы поддерживать многопроцессорную обработку согласно одному варианту осуществления изобретения. Слева от пунктирной разделительной линии 1200 находится среда выполнения со средствами поддержки графоориентированного программирования на основе производителей 1004. Справа от пунктирной разделительной линии 1200 находится решетка 1290. На стороне среды 1004 выполнения фиг.12A включает в себя из фиг.10 модуль 1070 выполнения графа производителей (включающий в себя модуль 1076 параллелизации, модуль 1077 многопроцессорной обработки, модуль 1078 многопоточной обработки и модуль 1079 локального выполнения) и диспетчер 1081 решетки. На стороне решетки 1290 фиг.12A включает в себя модуль 1270 удаленного вычисления.

Согласно одному варианту осуществления изобретения, если режимом выполнения производителя является многопроцессорная обработка, модуль 1076 параллелизации отправляет производителя в модуль 1077 многопроцессорной обработки. Модуль 1077 многопроцессорной обработки может создавать экземпляр задания, которое может включать в себя несколько задач. Модуль 1077 многопроцессорной обработки может создавать экземпляр задачи для производителя. Модуль 1077 многопроцессорной обработки дополнительно может преобразовывать в последовательную форму задачу, а также вводы в производитель и/или базисный экземпляр производителя. Затем модуль 1077 многопроцессорной обработки может добавлять последовательную форму задачи в задание. Модуль 1077 многопроцессорной обработки может отправлять задание в диспетчер 1081 решетки. После этого диспетчер 1081 решетки может отправлять задание в модуль 1270 удаленного вычисления решетки 1290. Подробности обработки задания посредством решетки 1290 поясняются ниже.

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

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

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

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

Фиг.12B показывает то, что объявления 1016 зависимостей производителя необязательно включают в себя условные зависимости 1210, подписные зависимости 1220 и несколько производителей 1215. Здесь несколько производителей 1215 упоминаются как возможность зависимости производителя возвращать совокупность производителей. Помимо этого, фиг.12B включает в себя подписной модуль 1240 и условный модуль 1230 в модуле 1040 автоматического формирования графов производителей, чтобы обрабатывать условные зависимости 1210 и подписные зависимости 1220. Фиг.12B также показывает то, что подписной модуль 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.

На фиг.13C 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) фиг.13I-J иллюстрируют использование сокращенного элемента, который является безусловным и который находится в операторе объявления зависимостей производителя для метода, на котором основан родительский стандартный производитель.

Фиг.13G иллюстрирует псевдокод объявлений зависимостей производителя для методов, используя сокращенную объявленную, условную, неподписную зависимость производителя и сокращенную объявленную, безусловную, неподписную зависимость производителя согласно одному варианту осуществления изобретения; тогда как фиг.13H - это блок-схема производителей, иллюстрирующая примерную сокращенную объявленную, условную, неподписную зависимость производителя и сокращенную объявленную, безусловную, неподписную зависимость производителя согласно одному варианту осуществления изобретения. Фиг.13G показывает: 1) оператор 1345 объявления зависимостей производителя для метода альфа 1305, при этом оператор 1345 объявления зависимостей производителя включает в себя сокращенную объявленную, условную зависимость производителя к производителю <P>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 объявления зависимостей производителя предоставляются посредством среды выполнения в ответ на сокращенную объявленную зависимость <P>GETC1::I1::M1 (который указывает то, что сокращенная используется для ключа класса). Метод fly1 1355 включает в себя код 1360 объявления зависимостей производителя, который задает DEP.TYPE как неподписную нисходяще объявляемую, задает DEP.PROD как производитель CX::I1::M1 или CY::I1::M1 в зависимости от значения C1, выводимого посредством производителя C0:I0::GETC1, и возвращает DEP. Хотя в примере по фиг.13H <P> используется для того, чтобы обозначать, что это - ключ класса производителя, который является условным, альтернативными вариантами осуществления изобретения могут использовать другие синтаксисы. Дополнительно, хотя в примере по фиг.13H <P> используется для того, чтобы обозначать то, что это - ключ класса производителя, который является условным, один вариант осуществления изобретения поддерживает имеющие больше и/или другие идентификаторы, которые составляют ключ производителя, быть указанными как условные этим способом.

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

Как ранее указано, в некоторых вариантах осуществления изобретения индикатор условной зависимости производителя поддерживается через синтаксис (к примеру, <P>), используемый в самом операторе объявления зависимостей производителя (см. 1345 фиг.13G), и такой синтаксис может использоваться для одного или более из класса, экземпляра и метода зависимости производителя. Указание "...условный" различных ключевых идентификаторов характера используется для того, чтобы идентифицировать, когда эта условная зависимость производителя возникает, тогда как "условный... идентификатор ключа метода определения" указывает ключ метода дочернего производителя (класс и экземпляр являются такими же, как в родительском производителе). В качестве примера зависимость производителя "<P>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 отслеживания экземпляров.

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

Фиг.16A - это блок-схема последовательности операций для создания экземпляров новых производителей и отмены подмены производителей согласно одному варианту осуществления изобретения. Со ссылкой на фиг.10, последовательности операций по фиг.16A выполняются посредством модуля 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 к методу и оператору объявления зависимостей производителя осуществляется доступ, и управление переходит к этапу 1623. Со ссылкой на фиг.10, этап 1620 выполняется посредством использования ключа метода из ключа производителя в столбце вызываемых производителей таблицы 2, чтобы осуществлять доступ к соответствующему одному из методов и объявлений 1056 зависимостей производителя из класса, найденного на этапе 1615.

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

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

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

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

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

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

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

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

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

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

Фиг.16B - это блок-схема последовательности операций для этапа 1623 по фиг.16A согласно одному варианту осуществления изобретения. Таким образом, управление переходит от этапа 1620 к этапу 16231 на этапе 1623. На этапе 16231 проверяется подмена настроек выполнения среды выполнения. Затем определяется то, активирована ли подмена настроек выполнения среды выполнения на этапе 16233. Если она задана, то режим выполнения задается согласно настройке выполнения среды выполнения на этапе 16234. Иначе основанная на производителе конфигурируемая структура решений для выбора режима выполнения от конечного пользователя проверяется на этапе 16235, и управление переходит к этапу 16236. На этапе 16236 определяется то, сделал ли конечный пользователь выбор какого-либо режима выполнения. Если да, то режим выполнения задается согласно настройке в основанной на производителе конфигурируемой структуре решений на этапе 16237. Иначе определение метода производителя проверяется для режима выполнения, заданного как примечание на уровне кода, и режим выполнения задается согласно примечанию на этапе 16238. От этапа 16238 или этапа 16237 управление переходит к этапу 16239, чтобы завершить процесс в рамках этапа 1623.

Фиг.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 ссылки на производителя определения зависимостей журнала 14А регистрации для данной поглощающей подписки).

На этапе 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).

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

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

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

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

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

В ответ на команду режима выполнения подмены (этап 2150) управление переходит к этапу 2155. На этапе 2155 настройка режима выполнения производителя подменяется в структуре 1060 графа производителей.

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

В ответ на среду команды подмены настроек режима выполнения среды выполнения (этап 2160), управление переходит к этапу 2165. На этапе 2165 настройка режима выполнения производителя подменяется глобально в структуре 1048 настройки среды выполнения.

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

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

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

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

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

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

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

На этапе 2208 задача считывается и удаляется из одной из очередей результатов выполнения задач поддерживаемых режимов выполнения. В текущих примерах очереди результатов выполнения задач включают в себя MP_RESULT_TASK_QUEUE, MT_RESULT_TASK_QUEUE и LOCAL_RESULT_TASK_QUEUE. От этапа 2208 управление переходит к этапу 2209.

На этапе 2209 среда выполнения определяет, должна ли постобработка производителей быть пропущена. Если сравнительное тестирование активировано, производители могут быть выполнены локально, а также подвергнуты многопроцессорной обработке. Таким образом, постобработка производителей пропускается после локального выполнения. Дополнительные сведения по сравнительному тестированию поясняются ниже. Возвращаясь к фиг.22A, если постобработка должна быть пропущена, то управление переходит к этапу 2248 на фиг.22B. Иначе управление переходит к этапу 2210.

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

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

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

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

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

На этапе 2248 очереди результатов выполнения задач проверяются, чтобы определять, являются ли они все пустыми. Если, по меньшей мере, одна из очередей результатов выполнения задач не является пустой, то управление переходит обратно к этапу 2208, чтобы продолжать обрабатывать результат в непустой очереди(ях) результатов выполнения задач. Иначе, если все очереди результатов выполнения задач являются пустыми, то управление переходит к этапу 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 определяется то, выполняются ли производители, от которых зависит текущий выбранный производитель. Если нет, управление переходит к этапу 2315; иначе управление переходит к этапу 2320. Относительно варианта осуществления изобретения, показанного на фиг.11C, столбец 1180 маркировок инкрементного выполнения для строк дочерних зависимостей проверяется, чтобы определять состояние выполнения дочерних элементов текущего выбранного производителя.

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

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

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

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

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

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

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

Фиг.25 и 26 - это блок-схемы последовательности операций для этапа 2207 по фиг.22 согласно одному варианту осуществления изобретения. Таким образом, управление переходит от этапа 2205 к этапу 2610 на фиг.25. На этапе 2610 создание экземпляра различных очередей задач для многопроцессорной обработки, многопоточной обработки и локального выполнения и задания для многопроцессорной обработки выполняется. Примерный способ выполнения этапа 2610 описан далее в данном документе. От этапа 2610 управление переходит к этапу 2620.

На этапе 2620 набор готовых производителей сканируется, чтобы обрабатывать производители в наборе один за другим. От этапа 2620 управление переходит к этапу 2622.

На этапе 2622 режим выполнения производителя считывается из структуры графа производителей, такой как структура графа на фиг.11C. Затем управление переходит к этапу 2625.

На этапе 2625 создается задача, ссылающаяся на производителя и вывод производителя. От этапа 2625 управление переходит к этапу 2630.

На этапе 2630 определяется то, в каком режиме выполнения производитель должен быть выполнен. В некоторых вариантах осуществления предусмотрено три поддерживаемых режима выполнения, а именно многопроцессорная обработка, многопоточная обработка и локальное выполнение. Если режим выполнения задается как локальное выполнение, управление переходит к этапу 2632. Если режим выполнения задается как многопоточная обработка, управление переходит к этапу 2634. Если режим выполнения задается как многопроцессорная обработка, управление переходит к этапу 2635.

На этапе 2632 задача производителя помещается в очередь выполнения задач для локального выполнения, т.е. LOCAL_EXECUTION_TASK_QUEUE. Затем управление переходит к этапу 2640.

На этапе 2634 задача производителя помещается в очередь выполнения задач для многопоточной обработки, т.е. MT_EXECUTION_TASK_QUEUE. Затем управление переходит к этапу 2640.

На этапе 2635 задача производителя помещается в очередь выполнения задач для многопроцессорной обработки, т.е. MP_EXECUTION_TASK_QUEUE. Затем управление переходит к этапу 2636. На этапе 2636, определяется то, запрошено ли сравнительное тестирование между удаленным выполнением и локальным выполнением. Если нет, управление переходит к этапу 2640. Тем не менее, если сравнительное тестирование запрошено, управление переходит к этапу 2637.

На этапе 2637 задача, помещенная в MP_EXECUTION_TASK_QUEUE, помечается так, чтобы пропускать обработку после выполнения. Затем новая задача, ссылающаяся на производителя и вывод производителя, создается и помещается в очередь выполнения задач для локального выполнения, т.е. LOCAL_EXECUTION_TASK_QUEUE, также на этапе 2638. Затем управление переходит к этапу 2639, чтобы сохранять в задаче, добавленной в MP_EXECUTION_TASK_QUEUE, ссылку на задачу, добавленную в LOCAL_EXECUTION_TASK_QUEUE, для последующего преобразования. После этапа 2639 управление переходит к этапу 2640.

На этапе 2640 определяется то, отсканированы ли все производители в наборе готовых производителей. Если нет, управление переходит обратно к этапу 2620, чтобы продолжать сканирование производителей в наборе готовых производителей. Иначе управление переходит к этапу 2642 на фиг.26B.

На этапе 2642 среда выполнения определяет, является ли MT_EXECUTION_TASK_QUEUE пустой. Если да, управление переходит к этапу 2660. Иначе управление переходит к этапу 2644.

На этапе 2644 среда выполнения инициирует механизм организации пула потоков, если еще не инициирован. От этапа 2644 управление переходит к этапу 2650.

На этапе 2650 создается экземпляр отдельного потока, чтобы выполнять многопоточную обработку для задач в MT_EXECUTION_TASK_QUEUE. Примерный способ выполнения этапа 2650 описан далее в данном документе. От этапа 2650 управление переходит к этапу 2660.

На этапе 2660 многопроцессорная обработка и локальное выполнение выполняются, чтобы выполнять задачи в MP_EXECUTION_TASK_QUEUE и LOCAL_EXECUTION_TASK_QUEUE. Примерный способ выполнения этапа 2660 описан далее в данном документе. От этапа 2660 управление переходит к этапу 2670.

На этапе 2670 определяется то, равен ли текущий размер MT_RESULT_TASK_QUEUE начальному размеру MT_EXECUTION_TASK_QUEUE. Если нет, то управление остается на этапе 2670, поскольку многопоточная обработка еще не закончена для всех задач в MT_EXECUTION_TASK_QUEUE. Иначе управление переходит от этапа 2670 к этапу 2690, и процесс на этапе 2207 завершается. Хотя многопоточная обработка, многопроцессорная обработка и локальное выполнение выполняются последовательно в примерной последовательности операций, описанной выше, следует принимать во внимание, что любая комбинация многопоточной обработки, многопроцессорной обработки и локального выполнения может быть выполнена параллельно в некоторых альтернативных вариантах осуществления.

Фиг.27A и 27B - это блок-схемы последовательности операций для этапа 2610 по фиг.26 согласно одному варианту осуществления изобретения. Таким образом, управление переходит от этапа 2205 к этапу 2710 на фиг.27A. На этапе 2710 определяется то, создан ли экземпляр MT_RESULT_TASK_QUEUE. Если да, то MT_RESULT_TASK_QUEUE очищается на этапе 2715. Иначе создается экземпляр MT_RESULT_TASK_QUEUE на этапе 2713. Затем управление переходит от этапа 2713 или этапа 2715 к этапу 2720.

На этапе 2720 определяется то, создан ли экземпляр MT_EXECUTION_TASK_QUEUE. Если да, то MT_EXECUTION_TASK_QUEUE очищается на этапе 2725. Иначе создается экземпляр MT_EXECUTION_TASK_QUEUE на этапе 2723. Затем управление переходит от этапа 2723 или этапа 2725 к этапу 2730.

На этапе 2730 определяется то, создан ли экземпляр MP_RESULT_TASK_QUEUE. Если да, то MP_RESULT_TASK_QUEUE очищается на этапе 2735. Иначе создается экземпляр MP_RESULT_TASK_QUEUE на этапе 2733. Затем управление переходит от этапа 2733 или этапа 2735 к этапу 2740.

На этапе 2740 определяется то, создан ли экземпляр MP_EXECUTION_TASK_QUEUE. Если да, то MP_EXECUTION_TASK_QUEUE очищается на этапе 2745. Иначе создается экземпляр MP_EXECUTION_TASK_QUEUE на этапе 2743. Затем управление переходит от этапа 2743 или этапу 2745 к этапу 2750 на фиг.27B.

На этапе 2750 определяется то, создан ли экземпляр LOCAL_RESULT_TASK_QUEUE. Если да, то LOCAL_RESULT_TASK_QUEUE очищается на этапе 2755. Иначе создается экземпляр LOCAL_RESULT_TASK_QUEUE на этапе 2753. Затем управление переходит от этапа 2753 или этапа 2755 к этапу 2760.

На этапе 2760 определяется то, создан ли экземпляр LOCAL_EXECUTION_TASK_QUEUE. Если да, то LOCAL_EXECUTION_TASK_QUEUE очищается на этапе 2765. Иначе создается экземпляр LOCAL_EXECUTION_TASK_QUEUE на этапе 2763. Затем управление переходит от этапа 2763 или этапа 2765 к этапу 2620.

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

На этапе 2820 определяется то, является ли MT_EXECUTION_TASK_QUEUE пустой. Если MT_EXECUTION_TASK_QUEUE является пустой, т.е. все задачи в MT_EXECUTION_TASK_QUEUE поданы в соответствующий поток выполнения, то процесс заканчивается. Иначе, т.е. если имеется, по меньшей мере, одна задача, которая должна быть подана в поток выполнения, то управление переходит к этапу 2825, чтобы определять, есть ли какой-либо доступный поток в пуле. Если нет доступного потока в пуле, управление остается на этапе 2825 до тех пор, пока не появляется доступный поток. Когда имеется доступный поток, управление переходит к этапу 2830.

На этапе 2830 задача удаляется из MT_EXECUTION_TASK_QUEUE, и удаленная задача подается в доступный поток. Затем управление переходит обратно к этапу 2820, чтобы повторять этапы 2820, 2825 и 2830 до тех пор, пока все задачи не удалены из MT_EXECUTION_TASK_QUEUE. Отметим, что процесс на этапах 2820, 2825 и 2830 может быть выполнен посредством потока, экземпляр которого создан, чтобы не допускать блокировки остальной части потока.

Фиг.28B - это блок-схема последовательности операций, иллюстрирующая выполнение задачи в потоке наряду с необязательным обнаружением показателей. Если инструментальные средства запрошены, то среда выполнения начинает измерение времени выполнения задачи на этапе 2810. Иначе этап 2810 пропускается. От этапа 2810 управление переходит к этапу 2831. На этапе 2831 задача в потоке выполняется посредством вызова метода задачи с соответствующим экземпляром и вводами. То, когда выполнение задачи осуществлено, выводы и/или модифицированный экземпляр возвращаются из метода, и поток заканчивается. От этапа 2831 управление переходит к этапу 2815. Если инструментальные средства запрошены, то среда выполнения заканчивает измерение времени выполнения задачи на этапе 2815. Иначе этап 2815 пропускается.

Фиг.28C - это блок-схема последовательности операций для обработки в ответ на обратный вызов завершения потока согласно одному варианту осуществления изобретения. На этапе 2832, принимается обратный вызов завершения потока.

На этапе 2834 вывод задачи в завершенном потоке и полученные показатели (такие как время выполнения задачи), если таковые имеются, сохраняются в задаче, выполняемой посредством завершенного потока, и задача с выводом и полученными показателями, если таковые имеются, помещается в MT_RESULT_TASK_QUEUE. Затем управление переходит к этапу 2836. На этапе 2836 завершенный поток помечается как доступный в пуле потоков.

Фиг.29A и 29B - это блок-схемы последовательности операций для этапа 2660 по фиг.26 согласно одному варианту осуществления изобретения. Таким образом, управление переходит от этапа 2650 к этапу 2910 на фиг.29A. Отметим, что этапы, которые выполняются для инструментальных средств, но не используются для того, чтобы реализовать параллелизацию выполнения производителей, проиллюстрированы с помощью этапов, имеющих ломаные пунктирные границы на фиг.29A и 29B.

На этапе 2910 проверяется то, является ли MP_EXECUTION_TASK_QUEUE пустой. Если MP_EXECUTION_TASK_QUEUE является пустой, нет задачи, которая должна быть подвергнута многопроцессорной обработке, и, таким образом, управление переходит к этапу 2670. Иначе управление переходит к этапу 2915.

На этапе 2915 создается экземпляр задания, и идентификатор задания выделяется заданию. Кроме этого, на этапе 2915 также создается экземпляр TASKS_LOCAL_MAP. Затем управление переходит к этапу 2918. Если инструментальные средства запрошены, этап 2918 выполняется, чтобы начинать измерение полного времени выполнения задания. Иначе этап 2918 пропускается. Затем управление переходит к этапу 2920.

На этапе 2920 задача считывается и удаляется из MP_EXECUTION_TASK_QUEUE. Управление затем переходит к этапу 2921. Если инструментальные средства запрошены, этап 2921 выполняется, чтобы начинать измерение полного времени выполнения задачи. Иначе этап 2921 пропускается. Затем управление переходит к этапу 2923.

На этапе 2923 уникальный идентификатор задачи выделяется задаче и сохраняется со ссылкой на задачу в TASKS_LOCAL_MAP. Затем управление переходит к этапу 2925, чтобы создавать экземпляр последовательной формы задачи и заполнять последовательную форму задачи идентификатором задачи, именем класса и именем метода производителя, соответствующего задаче. Затем управление переходит к этапу 2930.

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

На этапе 2960 последовательная форма задачи добавляется в очередь последовательного выполнения задач для задания, а именно, JOB.SERIALIZED_TASKS_EXECUTION_QUEUE. Затем управление переходит к этапу 2965.

На этапе 2965 определяется то, является ли пустой MP_EXECUTION_TASK_QUEUE. Если MP_EXECUTION_TASK_QUEUE не является пустой, управление переходит обратно к этапу 2920, чтобы продолжать прохождение через оставшиеся задачи в MP_EXECUTION_TASK_QUEUE. Иначе управление переходит к этапу 2970.

На этапе 2970 задание отправляется в решетку из определенного числа удаленных процессоров. Решетка процессоров выполняет удаленное вычисление, чтобы выполнять задание. Подробности одной примерной последовательности операций способа поясняются в данном документе. Затем управление переходит к этапу 2972, чтобы выполнять локальное выполнение. От этапа 2972 управление переходит к этапу 2973.

На этапе 2973 определяется то, выполнено ли задание. Если нет, управление остается на этапе 2973 до тех пор, пока задание не выполнено. Когда задание выполнено, управление переходит к этапу 2975 на фиг.29B.

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

На этапе 2977 задача считывается и удаляется из очереди последовательных результатов задания, т.е. JOB.SERIALIZED_TASKS_RESULTS_QUEUE. Затем управление переходит к этапу 2979, чтобы находить ссылку на задачу с использованием идентификатора задачи, сохраненного в TASKS_LOCAL_MAP. Затем управление переходит к этапу 2980.

Если инструментальные средства запрошены, этап 2980 выполняется, чтобы определять размер последовательной формы вывода и начинать измерение времени локального преобразования из последовательной формы вывода. Иначе этап 2980 пропускается, и управление переходит к этапу 2981. На этапе 2981 вывод в выводе задачи преобразуется из параллельной формы. От этапа 2981 управление переходит к этапу 2982. К тому же, если инструментальные средства запрошены, этап 2982 выполняется, чтобы завершать измерение времени локального преобразования из последовательной формы. Дополнительно, если инструментальные средства запрошены, этапы 2984, 2985, 2987 и 2989 могут быть выполнены. Иначе этапы 2984, 2985, 2987 и 2989 пропускаются, и управление переходит от этапа 2981 к этапу 2990.

На этапе 2984 среда выполнения завершает измерение полного времени выполнения задачи и затем удаляет время локального выполнения из полного времени выполнения задачи. От этапа 2984 управление переходит к этапу 2985.

На этапе 2985 определяется то, запрошено ли сравнительное тестирование. Если сравнительное тестирование запрошено, управление переходит к этапу 2987, а затем к этапу 2989. Иначе управление переходит к этапу 2989 от 2985, чтобы пропускать этап 2987.

Как пояснено выше со ссылкой на фиг.25 и 26, сравнительное тестирование запрошено для того, чтобы сравнивать время локального и удаленного выполнения. Таким образом, задача выполняется и локально, и удаленно с использованием многопроцессорной обработки, если сравнительное тестирование запрошено согласно одному варианту осуществления изобретения. Таким образом, если сравнительное тестирование запрошено, среда выполнения может находить соответствующую задачу в LOCAL_RESULT_TASK_QUEUE на этапе 2987. Дополнительно, среда выполнения может добавлять время локальной обработки, сохраненное в задаче, к времени виртуальной локальной обработки задания. По сути, время виртуальной локальной обработки задания равно сумме времен локальной обработки всех задач в задании, когда все задачи выполнены. От этапа 2987 управление переходит к этапу 2989.

На этапе 2989 показатели задачи, такие как полное время выполнения задачи, наряду с идентификатором задания добавляются в задачу. Затем управление переходит к этапу 2990. Отметим, что оба этапа 2987 и 2989 выполняются, если инструментальные средства запрошены. Иначе оба этапа 2987 и 2989 могут быть пропущены.

На этапе 2990 задача помещается в MP_RESULT_TASK_QUEUE. Затем управление переходит к этапу 2991. На этапе 2991 определяется то, является ли JOB.SERIALIZED_TASKS_RESULTS_QUEUE пустой. Если нет, то управление переходит обратно к этапу 2977, чтобы продолжать считывание задач из очереди и преобразование из последовательной формы выводов. Иначе управление переходит к этапу 2992, если инструментальные средства запрошены. Если инструментальные средства не запрошены, то управление переходит от этапа 2991 к этапу 2670 на фиг.26B.

Если инструментальные средства запрошены, этапы 2992, 2993, 2995, 2996 и 2997 могут быть выполнены. Иначе этапы 2992, 2993, 2995, 2996 и 2997 могут быть пропущены. На этапе 2992 измерение полного времени выполнения задания заканчивается, и затем время локального выполнения удаляется из полного времени выполнения задания. От этапа 2992 управление переходит к этапу 2993.

На этапе 2993 определяется то, запрошено ли сравнительное тестирование. Если сравнительное тестирование запрошено, управление переходит к этапу 2995. На этапе 2995 ускорение выполнения задания вычисляется посредством деления времени виртуальной локальной обработки задания на полное время выполнения задания. Затем управление переходит от этапа 2995 к этапу 2996. На этапе 2996 эффективность выполнения задания вычисляется посредством деления ускорения выполнения задания на число процессоров, доступных и выделенных для выполнения задания в решетке. От этапа 2996 управление переходит к этапу 2997. Иначе, если сравнительное тестирование не запрошено, управление переходит от этапа 2993 непосредственно к этапу 2997.

На этапе 2997 показатели задания (к примеру, ускорение выполнения задания, эффективность выполнения задания, полное время выполнения задания и т.д.) добавляются в каждую задачу в рамках задания. От этапа 2997 управление переходит к этапу 2670 на фиг.26B.

Фиг.30 показывает блок-схему последовательности операций для этапа 2930 по фиг.29A согласно одному варианту осуществления изобретения. Таким образом, управление переходит от этапа 2925 к этапу 3010 на фиг.30. На этапе 3010 определяется то, создана ли уже последовательная форма входного производителя или базисного экземпляра в SERIALIZED_FORM_LOCAL_MAP на основе ключа входного производителя или ключа базисного экземпляра. Если последовательная форма уже создана, управление переходит к этапу 3015. Иначе управление переходит к этапу 3020.

На этапе 3015 идентификатор последовательной формы и последовательная форма считываются из SERIALIZED_FORM_LOCAL_MAP. Затем управление переходит к этапу 3040.

На этапе 3020 идентификатор последовательной формы выделяется входному производителю или базисному экземпляру. Затем управление переходит к этапу 3022.

На этапе 3022 измерение времени локального преобразования в последовательную форму начинается. Затем управление переходит к этапу 3024.

На этапе 3024 последовательная форма создается для входного производителя или базисного экземпляра. Затем управление переходит к этапу 3026.

На этапе 3026 измерение времени локального преобразования в последовательную форму заканчивается. Затем управление переходит к этапу 3028.

На этапе 3028 размер последовательной формы ввода определяется. Затем управление переходит к этапу 3030.

На этапе 3030 ключ входного производителя или ключ базисного экземпляра, идентификатор последовательной формы и последовательная форма сохраняются в SERIALIZED_FORM_LOCAL_MAP. SERIALIZED_FORM_LOCAL_MAP может быть глобальной или выделяемой и освобождаемой на основе задания, в зависимости от различных факторов, таких как требования по памяти, требования к рабочим характеристикам и т.д. Затем управление переходит к этапу 3034.

На этапе 3034 размер последовательной формы ввода и время преобразования в последовательную форму сохраняются с идентификатором последовательной формы в SERIALIZED_FORM_LOCAL_MAP. Затем управление переходит к этапу 3040. Отметим, что этапы 3022, 3026, 3028 и 3034, описанные выше, выполняются, если инструментальные средства запрошены. Этапы 3022, 3026, 3028 и 3034 могут быть пропущены, если инструментальные средства не запрошены.

На этапе 3040 определяется то, находится ли идентификатор последовательной формы в JOB.SERIALIZED_FORM_MAP. Если да, то управление переходит к этапу 3045. Иначе управление переходит к этапу 3043.

На этапе 3043 идентификатор последовательной формы и последовательная форма сохраняются в JOB.SERIALIZED_FORMS_MAP. Затем управление переходит к этапу 3045.

На этапе 3045 идентификатор последовательной формы добавляется как ввод или как базисный экземпляр в последовательную форму задачи. От этапа 3045 управление переходит к этапу 3050.

На этапе 3050 определяется то, есть ли дополнительный входной производитель, еще не обработанный, или есть ли базисный экземпляр, еще не обработанный. Если есть, то управление переходит обратно к этапу 3010. Иначе управление переходит к этапу 2960 на фиг.29A.

Фиг.31A и 31B показывают блок-схемы последовательности операций удаленного вычисления для многопроцессорной обработки согласно одному варианту осуществления изобретения. К тому же этапы, проиллюстрированные ломаной пунктирной линией, выполняются, если инструментальные средства запрошены, и могут быть пропущены, если инструментальные средства не запрошены. Как пояснено выше, задание, включающее в себя число задач, соответствующее производителям, диспетчеризуется в решетку процессоров для выполнения. Каждый процессор в решетке, также называемый исполнителем, может кэшировать JOB_SERIALIZED_FORMS_MAP. Например, если задание хранит тысячу задач, и предусмотрено десять исполнителей, выполняющих эти задачи, JOB_SERIALIZED_FORMS_MAP отправляется один раз посредством диспетчера решетки в каждый исполнитель и кэшируется на уровне исполнителя. Когда задание закончено, диспетчер решетки отправляет команду исполнителю, чтобы освобождать кэш. Последовательность операций начинается на этапе 3108.

На этапе 3108 JOB_SERIALIZED_FORMS_MAP наряду с последовательной формой задачи, хранящей идентификаторы ввода, имя класса и имя метода, принимается от диспетчера решетки. Затем управление переходит к этапу 3110. На этапе 3110 класс находится с использованием имени класса, и метод находится с использованием имени метода. Класс и метод загружаются, чтобы воссоздавать задачу. Затем управление переходит к этапу 3112.

На этапе 3112 идентификатор ввода задачи или идентификатор экземпляра находятся из JOB.SERIALIZED_FORMS_MAP. Затем управление переходит к этапу 3120.

На этапе 3120 определяется то, найден ли идентификатор ввода. Если нет, управление переходит к этапу 3190, чтобы возвращать ошибку. Иначе управление переходит к этапу 3130.

На этапе 3130 определяется то, является ли запись JOB.SERIALIZED_FORMS_MAP, соответствующая идентификатору ввода, уже преобразованной из последовательной формы. Если она является уже преобразованной из последовательной формы, то управление переходит к этапу 3150. Иначе управление переходит к этапу 3132.

На этапе 3150 преобразованная из последовательной форма ввода извлекается. Затем управление переходит к этапу 3155.

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

На этапе 3138 соответствующая запись в JOB.SERIALIZED_FORMS_MAP заполняется преобразованной из последовательной формы. Затем управление переходит к этапу 3143.

На этапе 3143 экземпляр или стандартный ввод добавляется в определение задачи. Затем управление переходит к этапу 3155.

На этапе 3155 определяется то, обработаны ли все идентификаторы ввода (т.е. все стандартные вводы наряду с базисным экземпляром). Другими словами, определяется, была ли задача полностью воссоздана или преобразована из параллельной формы. Если да, управление переходит к этапу 3160 на фиг.31B. Иначе управление переходит обратно к этапу 3112, чтобы обрабатывать следующий идентификатор ввода.

Ссылаясь на фиг.31B, измерение времени удаленной обработки начинается на этапе 3160. Затем управление переходит к этапу 3162.

На этапе 3162 вызывается метод с соответствующим экземпляром и вводами. Как следствие выполнения, метод может возвращать вывод и/или модифицировать экземпляр метода. Среда выполнения принимает вывод, возвращенный из метода, и/или модифицированный экземпляр. Затем управление переходит от этапа 3162 к этапу 3166.

На этапе 3166 измерение времени удаленной обработки заканчивается. Затем управление переходит к этапу 3170.

На этапе 3170 измерение времени удаленного преобразования в последовательную форму начинается. Затем управление переходит к этапу 3172, чтобы преобразовывать в последовательную форму возвращенный вывод и/или модифицированный экземпляр и присоединять преобразованный в последовательную форму вывод и/или преобразованный в последовательную форму модифицированный экземпляр к задаче. Затем управление переходит к этапу 3174. На этапе 3174 измерение времени удаленного преобразования в последовательную форму заканчивается. От этапа 3174 управление переходит к этапу 3176.

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

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

Фиг.32 показывает блок-схему последовательности операций для этапа 2972 по фиг.29A согласно одному варианту осуществления изобретения. Таким образом, управление переходит от этапа 2970 к этапу 3202 на фиг.32. К тому же этапы, проиллюстрированные ломаной пунктирной линией, выполняются, если инструментальные средства запрошены, и могут быть пропущены, если инструментальные средства не запрошены.

На этапе 3202 измерение времени локального выполнения начинается. Затем управление переходит к этапу 3210.

На этапе 3210 задача удаляется из LOCAL_EXECUTION_TASK_QUEUE и выполняется локально посредством вызова метода с соответствующим экземпляром и вводами. Когда выполнение осуществлено, метод возвращает выводы и/или модифицированный экземпляр метода. Затем управление переходит к этапу 3212.

На этапе 3212 измерение времени локального выполнения заканчивается. Затем управление переходит к этапу 3220.

На этапе 3220 вывод задачи сохраняется в задаче. Затем управление переходит к этапу 3223.

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

На этапе 3230 задача помещается в LOCAL_RESULT_TASK_QUEUE. От этапа 3230 управление переходит к этапу 3240.

На этапе 3240 определяется то, является ли LOCAL_EXECUTION_TASK_QUEUE пустой. Если очередь является пустой, то управление переходит к этапу 2973 на фиг.29A. Иначе управление переходит обратно к этапу 3202, чтобы повторять процесс, чтобы выполнять другую задачу локально.

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

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

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