Поддержка управления версиями в языках и инструментальных средствах объектно-ориентированного программирования

Поддержка управления версиями в языках и инструментальных средствах объектно-ориентированного программирования

Иллюстрации

Показать все

Реферат

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

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

Предшествующий уровень техники

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

Отчасти это затрагивает процесс генерирования компьютеризованных инструкций (также упоминаемых в данной заявке как “программное обеспечение” или “программы”) для компьютеризованной системы. Первоначально, разработчик программного обеспечения должен был сначала обдумать требуемые функции или результаты, которые программа должна выполнять, и затем ввести соответствующие инструкции в текстовом формате в электронный текстовой файл, обычно в виде исходного кода программирования. В некоторых случаях, таких как с интерпретируемыми языками программирования (например, JavaScript, Perl и т.д.), компьютеризованная система непосредственно интерпретирует введенные инструкции в текстовом формате и выполняет требуемую функцию. В других случаях, таких как с компилируемыми языками программирования (например, С# произносится “си-шарп”, C++ и т.д.), инструкции в текстовом формате сначала компилируются в объектные или машинные коды, которые компьютеризованная система может исполнять.

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

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

В основном, запрашивающий компонент включает в себя ссылку на целевой компонент. Может оказаться, что запрашивающий компонент ссылается на конкретную версию целевого компонента (строгая ссылка). Ссылка на конкретную версию целевого компонента может иметь место, например, когда разработчик запрашивающего компонента имеет априорные сведения о целевом компоненте и желает сделать запрашивающий компонент явно зависимым от конкретной версии целевого компонента. Например, запрашивающий “компонент 1” может быть сконфигурирован для ссылки на целевую “версию 1.1” “компонента 3”, вызывая явную зависимость “компонента 1” от “версии 1.1” “компонента 3”. С другой стороны, может быть, что запрашивающий компонент ссылается на целевой компонент, который может существовать или может даже не существовать, когда запрашивающий компонент разрабатывался (свободная ссылка). Таким образом, разработчик ссылается на целевой компонент без априорных сведений о целевом компоненте. Следовательно, запрашивающий компонент может обнаружить существование версии целевого компонента на этапе выполнения. Например, “компонент 1” на этапе выполнения может найти “версию 2.1” “компонента 3”.

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

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

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

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

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

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

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

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

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

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

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

Перечень фигур чертежей

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

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

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

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

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

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

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

фиг.5В - примерная логическая блок-схема способа ограничения области применения компонента в соответствии с принципами настоящего изобретения; и

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

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

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

Варианты выполнения в объеме настоящего изобретения также включают в себя машиночитаемый носитель для переноса или хранения на нем машиноисполняемых инструкций или структур данных. Таким машиночитаемым носителем может быть любой доступный носитель, к которому может обращаться компьютер общего назначения или специального назначения. В качестве примера, но не ограничения, такой машиночитаемый носитель может содержать оперативное запоминающее устройство (ОЗУ, RAM), постоянное запоминающее устройство (ПЗУ, ROM), электрически стираемое программируемое ПЗУ (ЭСППЗУ, EEPROM), ПЗУ на компакт-диске (CD-ROM) или другое запоминающее устройство на оптических дисках, запоминающее устройство на магнитных дисках или другие магнитные устройства хранения данных, или любой другой носитель, который может использоваться для переноса или хранения требуемого средства программного кода в виде машиноисполняемых инструкций или структур данных, и к которым может обращаться компьютер общего назначения или специального назначения.

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

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

На фиг.1 показана примерная архитектура компьютера для применения на практике реализации настоящего изобретения, в которой определяющий модуль 100 принимает один или несколько запросов от запрашивающего компонента 105 на доступ к другому компоненту или программе, такому как компоненты 120, 125 и 130. Для целей данного описания изобретения и формулы изобретения “определяющий модуль” 100 может включать в себя модуль любого типа, исполняемые инструкции которого сконфигурированы, например, для идентификации ссылки на целевой компонент, которая включает в себя имя компонента и первоначально предполагаемую версию, и выбора соответствующего целевого компонента, который будет использоваться для выполнения запроса. В некоторых ситуациях это может включать в себя принятие решения в отношении того, что такого доступного целевого компонента нет, так что определяющий модуль 100 будет сконфигурирован на возврат ошибки. Как также подробно описывается ниже, определяющий модуль 100 также может быть сконфигурирован для идентификации другой информации, например, информации о том, какие другие компоненты уже стали доступны для доступа в системе, процессе или подпроцессе компьютера.

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

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

Как изображено на фиг.1, определяющий модуль 100 может принимать запрос или объявление от запрашивающего компонента 105 на доступ к целевому компоненту, такому как компонент 120, 125 и 130. Для целей данного описания и формулы изобретения термин “целевой компонент” соответствует компоненту, в отношении которого запрашивающий компонент стремится осуществлять доступ. Понятно, однако, что то является ли компонент целевым компонентом или запрашивающим компонентом, по существу, является вопросом перспективы, в зависимости от того, какой компонент запрашивает доступ к другому. По существу, изложение, применимое к целевым компонентам в данном описании изобретения и формуле изобретения, в равной степени может применяться к запрашивающим компонентам, и наоборот.

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

“Политика управления версиями”, для целей данного описания изобретения и формулы изобретения, включает в себя любое из заданного набора свойств, которое может быть передано с целевого компонента (например, 120, 125, 130) на определяющий модуль 100. Политика 131, 132 или 133 управления версиями определяет, может ли использоваться соответствующий целевой компонент 120, 125, 130 вместо версии заданного целевого компонента с меньшим номером версии. Политика управления версиями может включать в себя дополнительную информацию, предназначенную для использования определяющим модулем 100 для принятия решения в отношении того, может ли использоваться целевой компонент в заданной конфигурации. Таким образом, политика 132 управления версиями может задать, что целевой компонент 125 (версия 1.2) может использоваться, когда запрашивается версия 1.1. В некоторых вариантах выполнения политика управления версиями может находиться в предопределенном месте в целевом компоненте. В других реализациях политика управления версиями может передаваться на определяющий модуль 100, когда компонент устанавливается в системе, или когда выполняется первый запрос на доступ к заданному компоненту, и т.д.

Следовательно, запрашивающий компонент может запросить доступ к целевому компоненту посредством запроса конкретной версии целевого компонента, например, запроса 110 “версии 1.1” “компонента 1”. Если запрашивающий компонент 105 запрашивает или сконфигурирован для работы с конкретной версией целевого компонента, определяющий модуль 100 может предоставить запрашивающему компоненту 105 доступ к конкретной версии компонента, в зависимости от политики 131, 132, 133 управления версиями, которая присутствует в целевом компоненте. Как показано на фиг.1, например, запрашивающий компонент 105 запрашивает “версию 1” “компонента 1” посредством посылки запроса 110. Следовательно, определяющий модуль 100 разрешает доступ запрашивающему компоненту 105 к “версии 1.1” “компонента 1”, даже если в системе существует более поздняя версия “компонента 1”, например “версия 1.2” 125.

В противоположность этому, в некоторых вариантах выполнения запрос одной версии компонента приводит к доступу к другой (например, обновленной или более поздней) версии компонента. Например, запросом 100 может быть запрос на получение доступа к “версии 1.1” “компонента 1”. Однако политика 131 управления версиями может указать, что “версией 1.1” является компонент платформы (и, таким образом, наиболее поздняя версия “компонента 1” должна быть предоставлена в ответ на запрос). Кроме того, в некоторых реализациях, тем не менее, могут быть многочисленные версии заданного компонента платформы в системе.

По существу, запрашивающий компонент также может включать в себя информацию в своем запросе, которая указывает наименьшую возможную версию целевого компонента платформы, которую запрашивающий компонент 105 может принять. Например, может быть, что запрашивающий компонент 105 запрашивает “версию 1.4” “компонента 1” и что младшие версии “компонента 1” не должны возвращаться в ответ на запрос. Следовательно, определяющий модуль 100 может предоставить запрашивающему компоненту 105 доступ к “версии 3” “компонента 1”, даже если доступны “версия 1.1” и “версия 1.2”.

Когда все доступные версии запрашиваемого компонента имеют обозначения версии, которые младше, чем конкретная запрашиваемая версия, определяющий модуль 100 может возвратить соответствующий ответ (например, сообщение об ошибке) запрашивающему компоненту. Например, когда определяющий модуль 100 не имеет доступа к “версии 3” “компонента 1”, определяющий модуль 100 может послать сообщение об ошибке запрашивающему компоненту 105 в ответ на запрос “версии 1.4 или более старшей” “компонента 1”.

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

Использование значений сервиса, способствующих замене компонентов, особенно выгодно для выполнения незначительных изменений, которые имеют уменьшенную вероятность того, что вызовут несовместимость с другими компонентами, для исправления ошибок или для решения проблем безопасности, если относятся к компонентам библиотеки или платформы. Т.е. значения сервиса могут способствовать корректировке (“наложению заплат”) версии компонента. Например, если целевой компонент 120 идентифицируется как компонент библиотеки (так что версия 1.1 целевого компонента не должна заменяться), разработчик все же может обновить целевой компонент 120 посредством обновления (например добавления приращения) значения сервиса в номере версии компонента. Следовательно, обновленный целевой компонент 120 будет, по существу, другим сервисом “версии 1.1”.

На фиг.2А иллюстрируется примерная архитектура компьютера, которая принимает более новые версии существующих компонентов. Т.е. определяющий модуль 100 может принимать обновления для целевых компонентов, которые уже являются резидентными в соответствующей компьютеризованной системе. Например, определяющий модуль 100 может принимать компоненты 215 и 210 от поставщика сетевых услуг (не показан), подсоединенного к сети 240. Определяющий модуль 100 может принимать компоненты 215 и 210 в результате выполнения программы установки в соответствующей компьютеризованной системе (или на поставщике сетевых услуг).

Как описано, компоненты 210 и 215 включают в себя информацию о политике управления версиями, такую как, например, информация о том, что обновленный компонент 210 представляет собой обновление “версии 3” “компонента 2” и что компонентом является компонент платформы. Также, компонент 215 может включать в себя информацию в виде политики управления версиями о том, что компонентом 215 является компонент библиотеки или что компонент 215 сконфигурирован иначе, так что запрашивающему компоненту может быть предоставлен доступ к конкретной версии, представленной компонентом 215.

В ответ на прием компонентов 210 и 215 определяющий модуль 100 определяет, сохранить ли предыдущие версии (что может упоминаться как “параллельное” обновление) или заменить предыдущие версии (что может упоминаться как обновление “на месте”) каждого принятого обновленного компонента. Например, как показано на фиг.2А, компонентами 220 и 235 являются, соответственно, компоненты библиотеки и платформы. Более конкретно, в ответ на прием компонента 215 определяющий модуль 100 может идентифицировать, что, поскольку “компонентом 1” является компонент библиотеки, другие программы или компоненты могут быть сконфигурированы для доступа конкретно к “версии 1” “компонента 1”. Следовательно, определяющий модуль 100 может определить, что должны быть сохранены как компонент 215, так и компонент 220.

Более конкретно, в ответ на прием компонента 210 определяющий модуль 100 может идентифицировать, что, поскольку “компонентом 2” является компонент платформы, запрашивающим программам и компонентам будет предоставлен доступ к наиболее поздней версии компонента 2. Следовательно, определяющий модуль 100 может определить, что компонент 235 должен быть заменен компонентом 210.

На фиг.2В иллюстрируется примерная архитектура компьютера по фиг.2А, после того как определяющий модуль определил версии компонентов, которые должны быть сохранены. Как изображено на фиг.2В, как “версия 1” (компонент 220), так и “версия 2” (компонент 215) компонента 1 остаются в системе (параллельное обновление). Также, как изображено на фиг.2В, только “версия 3” “компонента 2” (компонент 210) остается в системе (обновление на месте).

На фиг.3 иллюстрируется примерная архитектура компьютера для стратификации области применения компонента на различных уровнях обработки данных в соответствии с реализацией настоящего изобретения. Стратификация основывается на области применения компонента, которая применяется к целевым компонентам. В качестве объяснения, но не ограничения, на фиг.3 указаны три уровня области применения, т.е. уровень 330 “машины”, уровень 340 “процесса” и уровень 350 “подпроцесса”. Понятно, однако, после прочтения данного описания и формулы изобретения, что может быть большее или меньшее число уровней, как целесообразно. В частности, аспекты изобретения дают возможность целевому компоненту подать политику управления версиями, которая требует, чтобы только одна версия целевого компонента была сделана доступной на заданном уровне (т.е. только одна версия на всей машине, или только одна в заданном процессе, или только одна в заданном подпроцессе).

Например, политика управления версиями, которая связана с заданным целевым компонентом 300, может включать в себя набор области применения компонента. Обращаясь кратко опять же к фиг.1, область применения компонента может указывать на то, что запрашивающий компонент 105 должен осуществить доступ к целевому компоненту 300 на заданном уровне процесса. Как показано на фиг.3, например, “версия 1” 300 “компонента 1” идентифицируется для доступа на уровне машины. Любой запрашивающий компонент, установленный в системе, который запрашивает доступ к целевому компоненту 300, должен использовать “версию 1” “компонента 1”, так как целевой компонент 300 сконфигурирован для доступа на уровне машины. Как и в случае с другими свойствами политики управления версиями, данное ограничение уровня процесса может быть указано разработчиком целевого компонента до установки этого компонента в заданной системе.

Область применения компонента также может указывать большие или меньшие области применения для целевого компонента 300, 310, 315, 320 и 325. Например, “политики управления версиями”, идентифицированные с заданным компонентом 310, могут указывать, что заданная версия целевого компонента 310 требуется только в некотором процессе 342, 345 или подпроцессе 352, 355. Как показано на фиг.3, например, любой запрашивающий компонент 105, который запрашивает доступ к заданной версии компонента 310, может делать это в процессе 342 без необходимости того, чтобы другие запрашивающие компоненты (в системе) использовали этот же целевой компонент в других процессах 315. Как таковой, компонент 310 может использоваться в процессе 342, тогда как компонент 315 может использоваться в процессе 345. Кроме того, когда процесс А 342 не выбрал конкретную версию, подпроцесс 350, который зависит от процесса 340, может использовать различные версии компонента 310, такие как компоненты 320 и 325. Данный уровень гранулированного доступа к различным компонентам может, поэтому, указываться, когда заданный компонент разрабатывается, а не системным администратором, когда заданный компонент устанавливается в системе. Определяющий модуль 100 может объединять любую идентифицированную область применения компонента для каждого целевого или запрашивающего компонента для предоставления запрашивающему компоненту соответствующего доступа к целевому компоненту.

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

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

На фиг.4 изображена примерная логическая блок-схема способа предоставления доступа к компоненту в соответствии с реализацией настоящего изобретения. Способ по фиг.4 включает в себя действие 400 приема запроса версии целевого компонента. Действие 400 может включать в себя прием запроса на доступ к конкретной версии целевого компонента, причем этот запрос принимается от запрашивающего компонента. Например, запрашивающий компонент 105 может запросить доступ к целевому компоненту, такому как компонент 120, 125 и 130, при помощи определяющего модуля 100. Также может быть, что запрос включает в себя политику управления версиями версии целевого компонента.

Способ также включает в себя функциональный ориентированный на результат этап 440 предоставления соответствующего целевого компонента. Этап 440 может включать в себя любое количество соответствующих действий для реализации настоящего изобретения. Однако, как изображено на фиг.4, этап 440 включает в себя действие 410 идентификации политики управления версиями. Действие 410 может включать в себя идентификацию политики управления версиями конкретной версии целевого компонента. Если политика управления версиями была включена в запрос, то определяющий модуль 400 может идентифицировать такую включенную политику управления ве