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

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

 

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

Приоритет настоящей заявки основан на предварительной патентной заявке US 61/333235, поданной 10 мая 2010 г., под названием "Managing static data structures of legacy software in dynamic class loader environments with meta-data driven wiring", которая в порядке ссылки включена в настоящую заявку.

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

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

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

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

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

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

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

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

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

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

В некоторых вариантах осуществления классом моделей данных может являться класс Java, а представлением в памяти может являться объект Java. Идентификаторы внешнего типа могут задаваться с использованием XML. Специализированные реестры могут задаваться посредством одного из свойств системы Java.

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

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

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

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

на фиг.2 показана блок-схема, иллюстрирующая один из вариантов осуществления реализации заказного системного реестра пакета согласно настоящему изобретению,

на фиг.3 показана блок-схема, иллюстрирующая один из вариантов осуществления процесса инициализации согласно настоящему изобретению,

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

на фиг.5 показана блок-схема, иллюстрирующая один из вариантов осуществления процесса инициализации, согласно настоящему изобретению,

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

на фиг.7А и 7Б показаны блок-схемы, иллюстрирующие один из примеров процесса применительно к новому комплекту, поступающему в систему, и один из примеров процесса применительно к комплекту, выходящему из системы, согласно настоящему изобретению.

Подробное описание

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

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

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

На фиг.1 также показан переход от унаследованной системы 100 к системе 200. В систему 200 входит аппаратное обеспечение 210, операционная система 220 и среда 230 выполнения. Среда 230 выполнения является более сложной, чем среда 130 выполнения, и ей может являться любая среда выполнения с использованием системы динамических загрузчиков классов, в которой могут быть в явной форме определены зависимости, а не иерархической системы загрузчиков классов среды 130 выполнения. Аппаратным обеспечением 210 может являться любое сочетание процессоров, памяти, запоминающего устройства, сетевых устройств, маршрутизаторов, кабельной системы, передатчиков, приемников, устройств ввода-вывода, машин, механических устройств, электронных устройств и других физических ресурсов, в которых может быть реализована система 200, и оно может являться аналогичным или даже идентичным аппаратному обеспечению 110. Операционной системой 220 может являться любое сочетание выполняемого программного кода, данных и другого программного обеспечения или аппаратно-программного обеспечения, в котором может быть реализована система 200 в сочетании с аппаратным обеспечением 210, и оно может являться аналогичным или даже идентичным операционной системе 120.

Одни из примеров осуществления среды 230 выполнения в системе 200 является среда динамических загрузчиков классов, в которой используется графическая, неиерархическая система загрузчиков классов, такая OSGi. Программное обеспечение в среде OSGi может быть разделено на различные "комплекты". Каждому комплекту могут соответствовать метаданные конфигурации с указанием, например, названия комплекта, версии комплекта и информации о зависимостях классов. Затем метаданные каждого комплекта могут использоваться для построения графа зависимостей с указанием множества комплектов, от которого зависит данный комплект. В таком множестве зависимостей описаны классы, экземпляры которых может создавать этот комплект, и указаны классы, доступные для комплекта. В среде таких динамических загрузчиков классов каждая из множества версий конкретного комплекта существует по отдельности, при этом они могут одновременно использоваться другими версиями других комплектов в других графах зависимостей. Структура OSGi является средой иерархической системы загрузчиков классов, которая базируется поверх Java, но вместо того, чтобы поддерживать общий путь к классу для всех классов, OSGi поддерживает множество специализированных путей к классам.

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

Унаследованные программные средства 140 моделирования данных, разработанные для использования загрузчиками классов в менее сложных средах 130 выполнения, могут быть сконфигурированы на использование загрузчиками классов в средах 230 динамических загрузчиков классов посредством заказного системного реестра 250. В одном из вариантов осуществления, проиллюстрированном на фиг.2, программное обеспечение в среде 230 динамических загрузчиков классов разделено на комплекты: комплект А, комплект В, комплект В.2, комплект С и т.д. до комплекта X. Каждому комплекту программного обеспечения может соответствовать собственный специализированный системный реестр 250А-Х, отображающий на основании своего графа зависимостей множество внешних форматов, чьи классы внутренних форматов доступны ему. В целом эти специализированные реестры 250А-Х образуют системный суперреестр 250. Системный суперреестр может быть описан как системный реестр реестров. Ключами каждого специализированного системного реестра являются идентификаторы внешнего типа, соответствующие такому комплекту, а значениями специализированного системного реестра являются классы моделей данных, соответствующие ключам. Эти классы моделей данных определяют представление моделей данных в памяти. За счет этого подхода на основе множества системных реестров заданному комплекту программного обеспечения известно только, как воссоздать в памяти объекты моделей, к классам которых он может получить доступ. В случае множества версий конкретного комплекта, такого как комплект В и комплект В.2, каждый комплект имеет собственный системный реестр (250В и 250 В.2, соответственно), собственные зависимости и собственные версии представлений любых классов моделей в памяти.

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

Модели постоянных данных могут храниться в разнообразных формах, например, для обмена метаданными с помощью языка XML (XMI, от английского - XML Metadata Interchange). Файл XMI содержит информацию о типе модели в виде пространства имен QName в XML. Иными словами, QName однозначно идентифицирует модель данных, экземпляры которой были постоянно сохранены в файле XMI.

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

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

Архитектура загрузки классов в среде OSGi является значительно более сложной. Как описано выше, она определяет "комплекты" программного обеспечения, которые имеют собственные зависимости, и множество версий которых может существовать. В этой среде значительно легче поддерживать множество приложений, каждое из которых использует различные версии одинаковых моделей данных или полностью различные модели, имеющие одинаковые значения QNames XMI или имена Java пакетов. Среда является высоко динамичной: комплекты могут любой момент добавляться в систему и удаляться из системы. Вместо перезаписи EMF с целью работы в среде OSGi, что означало бы не только изменения в самой EMF, но также изменения в приложениях, которые используют EMF, в этом варианте осуществления EMF сконфигурирована на использование заказного системного реестра записи или чтения постоянного объекта, оптимизированного к OSGi, а не стандартного статического системного реестра EMF. Этот замена системного реестра осуществляется за счет использования обеспечиваемого EMF механизма, который допускает спецификацию альтернативных реализации системного реестра посредством одного из свойств системы Java. Следовательно, в этом варианте осуществления EMF и ее приложения могут оставаться преимущественно без изменений, и при этом выгодно используются расширенные возможности загрузки классов в OSGi.

Как показано на фиг.1 и описано выше, унаследованные программные средства 140 моделирования данных, разработанные для использования загрузчиками классов в менее сложных средах 130 выполнения, могут быть сконфигурированы на использование загрузчиками классов в средах 230 динамических загрузчиков классов путем управления одной или несколькими статическими структурами данных унаследованных программных средств моделирования данных. В одном из вариантов осуществления в систему и способ управления такой статической структурой данных (такой как системный реестр) могут входить без ограничения заказной системный реестр 250, инициализатор и обработчик.

Заказной системный реестр

На фиг.2 проиллюстрирована реализация заказного системного реестра 250 в унаследованных программных средствах 140 моделирования данных. В одном из вариантов осуществления заказным системным реестром 250 может являться системный реестр пакета базовой структуры моделирования Eclipse (EMF). Стандартное программное обеспечение EMF позволяет его пользователям устанавливать реализацию заказного системного реестра пакета, заменяющую реализацию стандартного системного реестра. В одном из таких вариантов осуществления реализация стандартного системного реестра 150 заменяется заказным системным реестром 250, более приспособленным к среде 230 динамических загрузчиков классов (смотри фиг.1). С точки зрения EMF эта реализация стандартного системного реестра 250 выглядит как единый системный реестр, но в действительности, она представляет собой множество реестров: по одному системному реестру 25 ОА-ОХ на каждый комплект А-Х программного обеспечения. Этот множество реестров может быть описан как системный суперреестр.

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

Инициализатор

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

На фиг.3 показан блок-схема 300, иллюстрирующая один из примеров процесса инициализации системы из множества системных реестров. Инициализатор проверяет все комплекты, доступные в данный момент в среде динамических загрузчиков классов. Если после проверки на шаге 310 в среде остаются непроверенные комплекты программного обеспечения, на шаге 320 инициализатор проверяет следующий комплект программного обеспечения. Затем на шаге 330 инициализатор определяет классы моделей данных, соответствующие этому комплекту программного обеспечения, а затем на шаге 340 конструирует системный реестр для этого комплекта программного обеспечения. Инициализатор может использовать метаданные, соответствующие комплекту программного обеспечения, чтобы определить соответствующие комплекту классы моделей данных. Ключами сконструированного системного реестра может являться множество идентификаторов внешнего типа, которые соответствуют определенным на шаге 330 классам моделей данных. Значениями системного реестра могут являться классы моделей данных. После конструирования на шаге 340 системного реестра инициализатор возвращается к шагу 310. Если в среде остаются непроверенные комплекты программного обеспечения, процесс повторяется. Если после проверки на шаге 310 в среде не остается непроверенных комплектов программного обеспечения, процесс инициализации завершается.

На фиг.4 показана блок-схема 400, иллюстрирующая другой пример процесса инициализации системы из множества системных реестров. Инициализатор проверяет все комплекты, доступные в данный момент в среде динамических загрузчиков классов. Если после проверки на шаге 410 в среде не остается непроверенных комплектов программного обеспечения, на шаге 420 инициализатор проверяет следующий комплект программного обеспечения. Затем на шаге 430 инициализатор устанавливает, определен ли в этом комплекте программного обеспечения один или несколько классов моделей данных. Если это так, на шаге 440 эти классы моделей добавляются в специализированный системный реестр этого комплекта. Ключами системного реестра может являться множество идентификаторов внешнего типа, которые соответствуют классам моделей данных, а значениями системного реестра могут являться классы моделей данных.

После обработки любых классов моделей данных, определенных в комплекте, на шаге 450 инициализатор строит граф зависимостей, в котором указаны все остальные комплекты, от которых прямо или косвенно зависит этот комплект, и создает подмножество зависимостей комплектов программного обеспечения. Если после проверки на шаге 460 в подмножестве зависимостей остаются непроверенные комплекты программного обеспечения, на шаге 470 инициализатор проверяет следующий элемент подмножества. Затем на шаге 480 инициализатор устанавливает, определен ли в этом элементе подмножества один или несколько классов моделей данных. Если это так, на шаге 490 эти классы моделей добавляются в специализированный системный реестр комплекта программного обеспечения. Если после проверки на шаге 460, в подмножестве зависимостей остаются комплекты программного обеспечения, обрабатывается следующие элемент подмножества. После того, как обработаны все элементы подмножества зависимостей, системный реестр данного комплекта заполнен. Если после проверки на шаге 410 в среде остаются непроверенные комплекты программного обеспечения, весь процесс повторяется для всех остающихся комплектов программного обеспечения. Если после проверки на шаге 410 в среде не остается непроверенных комплектов программного обеспечения, процесс инициализации завершается.

На фиг.5 показана блок-схема 500, иллюстрирующая другой пример процесса инициализации системы из множества системных реестров. Инициализатор проверяет все комплекты, доступные в данный момент в среде динамических загрузчиков классов. Если после проверки на шаге 505, в среде остаются непроверенные комплекты программного обеспечения, на шаге 510 инициализатор проверяет следующий комплект программного обеспечения. Затем на шаге 515 инициализатор устанавливает, был ли ранее сконструирован фрагмент системного реестра для данного комплекта программного обеспечения. Такой фрагмент системного реестра может содержать, например, отображения процесса записи или чтения постоянного объекта только данного комплекта. Если на шаге 515 установлено, что фрагмент системного реестра недоступен, на шаге 520 инициализатор устанавливает, определен ли в этом комплекте программного обеспечения один или несколько классов моделей данных. Если это так, на шаге 525 конструируется фрагмент системного реестра, и на шаге 530 классы моделей в сконструированном фрагменте объединяются со специализированным системным реестром этого комплекта. Однако, если на шаге 515 установлено, что для комплекта программного обеспечения доступен фрагмент системного реестра, на шаге 530 фрагмент объединяется со специализированным системным реестром и тем самым устраняются избыточные вычисления в системном реестре.

После обработки или конструирования фрагмент системного реестра комплекта на шаге 535 инициализатор строит 535 граф зависимостей с указанием всех остальных комплектов, от которых прямо или косвенно зависит данный комплект, и создает подмножество зависимостей комплектов программного обеспечения. Если после проверки на шаге 540 в подмножестве зависимостей остаются непроверенные комплекты программного обеспечения, на шаге 545 инициализатор проверяет следующий элемент подмножества. Затем на шаге 550 инициализатор устанавливает, был ли ранее сконструирован фрагмент системного реестра для данного элемента подмножества. Если на шаге 550 установлено, что фрагмент системного реестра недоступен, на шаге 555 инициализатор устанавливает, определен ли в этом элементе подмножества один или несколько классов моделей данных. Если это так, на шаге 560 конструируется фрагмент системного реестра, и на шаге 565 классы моделей в сконструированном фрагменте объединяются со специализированным системным реестром этого комплекта. Однако, если на шаге 550 установлено, что для элемента подмножества доступен фрагмент системного реестра, на шаге 565 существующий фрагмент объединяется со специализированным системным реестром. Если после проверки на шаге 540 в подмножестве зависимостей остаются непроверенные комплекты программного обеспечения, обрабатывается следующий элемент подмножества. После того, как обработаны все элементы подмножества зависимостей, системный реестр данного комплекта заполнен. Если после проверки на шаге 505 в среде остаются непроверенные комплекты программного обеспечения, весь процесс повторяется для всех остающихся комплектов программного обеспечения. Если после проверки на шаге 505 в среде не остается непроверенных комплектов программного обеспечения, процесс инициализации завершается.

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

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

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

Обработчик событий комплекта OSGi

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

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

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

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

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

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

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

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

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

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

3. Способ по п. 1, в котором среда динамических загрузчиков классов содержит OSGi.

4. Способ по п. 1, в котором унаследованные программные средства моделирования данных содержат EMF - базовую структуру моделирования Eclipse, при этом по меньшей мере один класс моделей данных содержит класс Java, а представление в памяти по меньшей мере одного класса моделей данных содержит собой объект Java.

5. Способ по п. 4, в котором идентификаторы внешнего типа указывают с использованием XML - расширяемого языка разметки.

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

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

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

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

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

11. Способ по п. 10, в котором второй комплект программного обеспечения представляет собой элемент первого подмножества зависимостей.

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

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

14. Система по п. 12, в которой среда динамических загрузчиков классов содержит OSGi.

15. Система по п. 12, в которой унаследованные программные средства моделирования данных содержат EMF - базовую структуру моделирования Eclipse, при этом по меньшей мере один класс моделей данных содержит класс Java, а представление в памяти по меньшей мере одного класса моделей данных содержит объект Java.

16. Система по п. 15, в которой идентификаторы внешнего типа указывают с использованием XML - расширяемого языка разметки.

17. Система по п. 15, в которой замена стандартного системного реестра унаследованных программных средств моделирования данных системным суперреестром содержит указание системного суперреестра посредством одного из свойств системы Java.

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