FR2773242A1 - METHOD FOR IDENTIFYING AND MONITORING EVOLUTIONS OF A SET OF SOFTWARE COMPONENTS - Google Patents

Abstract

The invention concerns a method for identifying and monitoring the evolution of an set of software components (4), each component (#1 to N) being marked by a name and a version identifier, and each set of software components (4) being linked to a first subset (5) comprising an identifier (50, 51) of the software set and its version. The modifications brought to the software components (#1 to N) are marked by a correction package index which is incremented when a new correction package is applied. A second subset (6) is provided comprising an identifier (60) of the software set (4) and of the correction package, and of an evolution version number (61) comprising at least the correction package index. Said second subset (6) is associated (l2) with a file (7') describing the name of the software components (#3, #5) of the correction package and their versions.

Description

METHOD FOR IDENTIFYING AND MONITORING EVOLUTIONS
A SET OF SOFTWARE COMPONENTS
The present invention relates to a method for identifying and monitoring changes in a set of software components.

 A software product is usually made up of a set of unitary components that are perfectly identified by a series of information, such as the date of creation, stamp of the type of version, etc., which makes it possible to follow their evolutions.

 However, there is generally no unambiguous identification of the software product considered in its entirety and for monitoring the evolution of each of its components.

 In addition, when one is interested in a software solution that consists of a set of software products, which moreover can be heterogeneous and multivendor, there is no way to globally identify this set, or especially to follow his evolution.

 However, the control of the state of each unit component of a software solution, which consists in ensuring that it is at a given level (ie a given version), is the only way to guarantee its integrity.

 This problem already arises with some acuteness for the small systems (microcomputers) and the average systems ("minicomputers or computers said" departemen rate "), all the more that the power of these systems increase regularly. It is easy to understand that the problem raised is even more acute for very large systems or "mainframe", according to the English terminology.

 Also, the method of the invention relates more particularly to systems of this type and will briefly recall the main features.

 These systems, very complex, integrate many subsystems, both hardware and software that cooperate with each other. It is not uncommon for software products constituting these systems to have hundreds of thousands or even millions of lines of code.

 In this context, one of the most difficult problems to solve is to obtain coherence and compatibility between the various components, especially when they need to be updated (change to newer versions, add modules or functions, etc.).

 Indeed, in addition to the intrinsic complexity recalled, it must also be taken into account that the different products making up the system have disparate origins, whether internally (even if common development rules are in force) or externally (products available on the market).

 In the state of the art, there are two main types of architectures.

 A first architecture belongs to the type called "owner". Under this term, we designate systems whose architecture is designed by the hardware manufacturer.

 The architecture is essentially characterized by a strong integration and is in the form of a monolithic system.

 In this system, all components of the set are taken into account during the initial installation and during subsequent updates (system version change). In this type of environment, the coherence of the system is obtained by the global validation of the interfaces between all the components. For the user, these provisions guarantee a great robustness of the system independently of its evolutions. In addition, they allow simplified monitoring of successive versions of the system.

Finally, they ensure maximum availability and high operational safety, since the risks of malfunction are reduced to a minimum.

 However, there are in return serious constraints and disadvantages.

 These originate in the fact that the systems are monolithic. Whatever the component to be changed and / or the function to be added, it is necessary to change the whole system. The update can only be global.

 Finally, the update results in a significant unavailability of the data processing system, usually several days for very large systems.

 It follows that this type of architecture has relatively little flexibility and presents limited possibilities of evolution.

 A second architecture belongs to the so-called "open" type. Under this term, we designate systems whose architecture is not defined by a single manufacturer.

These systems have appeared, in particular, with the emergence of operating systems of the "UNIX" (registered trademark) or similar type, for example "AIX" (registered trademark).

 It is clear that this type of architecture is very attractive because it allows to use heterogeneous software, that is to say, of different origins coexisting on the same machine.

 For this type of architecture, the installation and / or update of a software concern only the product itself, and not the system as a whole.

 Since basic components can be installed or updated at any time, an "open" architecture therefore offers great flexibility and ease of evolution, at least in theory.

 Indeed, this type of architecture is not free of disadvantages. In particular, it offers no guarantee of correct operation with the other software components: various incompatibility possibilities, etc.

 However, despite the disadvantages inherent in it, an open architecture system remains very attractive to users.

Indeed, it makes it possible to satisfy all or part of the needs of users of computer systems that are currently being felt, among which
- autonomy, that is to say the possibility of changing one or more products of the system, independently of the rest of the system
- parallelism, that is to say the possibility of running several versions of the same product simultaneously
- compatibility, that is to say, to be able to count on a guarantee of ascending compatibility of products and interfaces between products
- update during the current operation of the system, that is to say, be able to change version of a product without stopping the operation or, at the very least, with a minimum stop
- backtracking, that is to say the possibility of returning to an earlier version of a product in case of a problem, without stopping the operation
- control of evolutions, that is to say the possibility of remaining in control of the evolution process by the implementation of automated and simplified procedures
- and rapid evolutions and maintenance, that is to say, to be able to count on a minimum delay between a request for evolution or correction, and its actual installation on site.

 To overcome the disadvantages of the two types of architectures mentioned above, while retaining the advantages of each, the Applicant has proposed, in a French patent application No. 97 08332, filed on July 2, 1997, entitled "Architecture of the treatment system of information ", a solution to fully meet the needs of users who have just been recalled.

 To do this, the information processing system has an architecture in domains.

 A domain is defined as a set of features offered by system software components. It has its own characteristics and evolves independently. The system is then composed of a set of domains with a minimum of interdependencies, which guarantees overall consistency.

 In other words, the installation flexibility and the update are introduced at a macroscopic level which remains controllable, that is to say the domain in which the coherence remains ensured.

 Each domain, whatever it may be, is "seen" identically by the user, thanks in particular to the attributes assigned to it and a descriptor.

 Figure 1 attached to this description schematically illustrates such architecture called "domains".

 The system 1 comprises a hardware platform 10.

According to an important feature of the aforementioned patent application, all the software and firmware is divided into domains, 11 to 13. More particularly, there is a set of domains, D1, D2 ..., Dj, .. ., Dn, regrouped under the general reference 12, and two specific domains, 11 and 13. The latter two domains are, respectively, the domain 11 providing the operating system (or "OS") and the associated basic software of the system, and the domain 13 providing the operating monitor system 1. The system 1 therefore comprises at least these two areas, 11 and 13, in addition to the hardware platform 10.

This is the version of Domain 13, the system's operating monitor, which fully identifies the entire system 1 and its basic components, ie the different domains and the functionalities they offer.

 The indices j and n identifying the domains are purely arbitrary, j being an intermediate index and n being the maximum number of domains (not including the specific domains il and 13), at least in a given configuration state of the system.

 The other domains, 12, are optional and are selected by the user according to his specific needs and the application in question. These domains may be called "unmarked domains" in the sense that they are similarly "seen" by the system, even if their content is different. System 1 is therefore fully modular at the domain level.

 For the sake of clarity, the following areas can be implemented in the system: system administration functions, batch functions, database management functions, security function, transactional process management functions, and interoperability functions.

 A determined system 1, meeting the needs of the user, is installed in a given state. In other words, the configuration and domain versions are precisely defined.

This installation can be obtained in two ways
- This is first of all the initial installation itself, which can be called "turnkey", that is to say, a pre-configuration performed in the factory.

 - It can also be an incremental update of the machine on the operating site. The updates then relate to one or more domains, as needed. But it is never necessary, unlike "proprietary" type systems of the prior art, to modify the entire system 1.

There are actually two main types of update
- The actual update (or "update" according to the English terminology): a given domain, Dj, having been the subject of an initial installation, it is a matter of installing a newer version for incorporate either new features or corrections. This operation involves changing the version of the domain.

 - Added (or "add-on" according to the English terminology): it is the pure and simple addition of a particular domain, for example Dn, which had not been initially installed.

 It must also be clear that one or more domains can be deleted.

All domains, 11 to 13, cooperate with the hardware platform 10, directly or via the base domain or system 11. Similarly, all the "unmarked" domains 12 cooperate with the specific domains, 11 and 13. Vertical links ( in Figure 1) illustrate this mode of operation.
it is advantageous for the domains 12 to have the greatest independence from one another. In other words, it is important that the interactions between these domains be minimized. Generally, however, there are relationships between some of the domains D1 to Dn.

These relationships have been represented by horizontal links (in Figure 1).

 Although the number of domains is not, a priori, limited, in practice, the reasonable number of domains is preferably less than ten and, in any case, should be in the range of ten to twenty at most.

 In the opposite case, the complexity increases very importantly: function in x (x-1) / 2, with x total number of domains. The advantages provided by the architecture according to the invention are then greatly reduced.

 In summary, the domain architecture that has just been recalled allows to combine the advantages of "owner" and "open" architectures robustness, availability, security, flexibility and scalability.

 It therefore has many advantages, but there remains however a drawback which will be explained below.

 As previously indicated, the architectures according to the known art allow, for the most part, only the identification of each unitary component, which makes it very difficult to follow its evolution and to know its state with respect to a duly referred reference. qualified.

 On the other hand, the architecture in domains makes it possible to characterize well the initial state of a domain, that is to say of a software set comprising several components, but does not allow the identification and the follow-up of the evolutions of this software package.

 In this respect, despite its certain advantages, domain architecture therefore leaves a disadvantage common to other architectures.

 The aim of the invention is to overcome the disadvantages of the methods of the prior art.

She sets for goals
- to identify the state of a set of software products
to check the coherence of this set with respect to a reference
- and to follow the evolution of this set.

 To do this, the method according to the invention consists in providing a structure allowing the management and monitoring of the evolution of a coherent software package.

 This structure comprises a unitary component consisting of a record related to the aforementioned software package and perfectly identifiable by the system, whose configuration will be detailed below. In particular, this component is linked to a set of files allowing the tracking of evolutions and a reference file containing the unitary identifications of each modified component.

 Although the method according to the invention applies preferentially to an architecture in domains as it comes beech remembered, it can not be limited to this type of architecture.

 However, to fix the ideas, the method of the invention will be described below in the context of this preferred application, unless otherwise indicated.

 The subject of the invention is therefore a method for identifying and monitoring changes in a set of software components determined in an information processing system, each component being identified by a name and a version identifier, and each set of software components being linked to a first subset comprising an identifier of said software set and its version, characterized in that the modifications made to all or part of said components of a set of determined software components are identified by an index called a set of corrections, in that the determined set of software components is associated with a second subset comprising an identifier of said determined set of software components and said set of corrections and an evolution version identifier, this version identifier of evolution comprising at least said correction batch index, and that said second subset is linked to at least a first sequence of records describing the names of the components of said batch of corrections and their versions.

The invention will be better understood and other features and advantages will appear on reading the following description with reference to the appended figures, among which:
FIG. 1 schematically illustrates an architecture of information processing system in domains
FIG. 2 schematically illustrates the structure of a domain, a basic constituent element of the architecture of FIG. 1
- Figure 3 illustrates an example of hierarchical organization of domains
- Figure 4 illustrates a particular area and its relationship to other areas of the system
FIGS. 5a to 5c schematically illustrate the method according to the invention.

 The method according to the invention will be described, as indicated in the context of the preferred application of the invention, that is to say in the context of an architectural information processing system. in domains.

 Also, it appears first of all useful to describe, in greater detail, with reference to FIG. 2, an elementary unit that constitutes a domain, Dj, of arbitrary index j.

 A Dj domain can be defined as an independent integration, installation, and update unit. It includes one or more software or packages of various origins: internal or external, which will be called products. By "internal" is meant "owner" type applications. By "external" is meant applications available on the market.

 More specifically, a domain comprises two main parts.

 A first part 3 consists of the various products offering domain-specific features, labeled 30 to 32. For example, a batch processing domain will offer at least the following functions: print management and backups.

 The second part 2 constitutes a particular interface of the domain Dj, which can be called a descriptor which gives access to data describing the domain and its properties.

 The functionalities provided by the Dj domains are supported by products that are characterized, among other things, by the way they are integrated into the system 1, by the way they are installed and run, and by the other products (c that is to say the other domains) on which they depend eventually.

 Part 2 or descriptor must therefore provide access to information characterizing a particular domain Dj, including an identifier concerning its name and version, and a list of its components. In addition, a domain Dj is characterized by a number of attributes, as indicated. All of this information is necessary to perform the above basic installation and updating of domains. They also describe the mode of operation of the products composing the domain.

 In a preferred embodiment, the attributes are three in number, namely the insertion level, the type of occurrence and the dependencies.

 An example of practical organization of a domain Dj will now be described in detail, with reference to FIG.

 In this practical example, the domain is organized according to a hierarchy of objects.

 For the sake of simplification, a domain Dj containing only a single product Pi will be considered below, it being understood that these provisions apply equally well to domains comprising several products. It is clear that the basic structure of a domain is the product, a domain comprising one or more products.

 However, a four-level hierarchical structure can be distinguished in an advantageous embodiment.

 The first level is the product Pi itself.

It is a homogeneous whole offering a given functionality. The product consists of a set of modules
Mil to Mi3 (three in the example described in Figure 3) or "packages", which constitute the second hierarchical level.

 The second level therefore groups the Mil modules to Mi3. A Mil module Mi3 is a homogeneous functional subset of a product Pi. It consists of a set of filesets FSil, FSi2 and FSi31 and FSi32 (in the example described in FIG. 3).

 These two levels constitute a first level of external visibility, NVe, that is to say "visible" by the user for an update of the domain Dj and / or its initial installation.

 It is thus possible to install all or part of the products of a Dj domain, as well as all or part of the modules composing them, naturally taking into account consistency constraints related to these products.

The third level groups the filesets
FSil, FSi2 and FSi31 and FSi32. A set of files is a set of files contributing to the realization of all or part of the functionalities offered by a module. A module, for example the modules Mil and Mi2, may comprise only one set of files, FSil and FSi2, respectively. On the contrary, a module may comprise two or more sets of files. This is the case of the Mi3 module which includes two sets of files, FSi3l and FSi32.

The fourth level is constituted by the files themselves, Fill, Fi12 Fui211 Fi22 Fui311 Fi321 and Fi322
Each set of files may include one or more files.

 The third and fourth levels constitute a level of internal visibility NVi, not visible to the user in normal use. However, the updates are for this level.

 A Dj domain is therefore a set of products and modules. It always includes, at a minimum, a module and a set of specific files describing the Dj domain. This set of specific files includes, at least, a specific file containing the list, that is, the name and version number, of all the other file sets of the domain Dj. In addition to its container role, this particular file serves to ensure the consistency of the domain Dj. Indeed, all the other file sets of the domain Dj are declared dependent on the set of specific files.

The installation or update of any set of files belonging to the domain Dj is only possible if the version of the domain allows it, at least as far as the controlled or integrated products are concerned. that is, a sufficiently high insertion level.

 Finally, in a particular embodiment of a domain architecture, illustrated schematically in FIG. 4, the system 1 may comprise a third specific domain, 14, which may be called a service domain or a "tools" domain.

 This domain includes, in particular, software products or utilities, also specific, allowing the installation and / or updating of all or part of the domains, D1 to Dn, and in each domain, of all or part of the products, they are of internal origin, that is to say a priori fully integrated domains, or external, these external products are controlled or not, depending on the level of insertion associated with the domain.

Naturally, the tools, or "engines", of installation and updating present in this field interact with the domains, D1 to Dn, as well as with the base domain 11, and the operating monitor domain. 13, and more particularly with their descriptor sets 2. The installations are performed according to rules recorded in the domain 14 and / or the descriptor sets 2.

 Referring again to FIG. 2, what has been called descriptor 2 gives access to at least one record 20, containing the name and version of the domain Dj, to a record 21 describing the attributes associated with this domain. and a record 22, description of the content of the domain and a set of rules for installing and updating the domain and products component. As described with reference to FIG. 3, each Dj domain has a specific set of files containing the list of other file sets, i.e., at least their names and version numbers. This information can also be supplemented by scripts and rules for installing and updating products outside the domain.

 Although the information recalled above can be distributed within a given domain, it is "seen" from the outside in the same way, via the descriptor set 2 which constitutes a standard interface for all domains, even if the content of the information accessed differs from one domain to another.

 The method according to the invention will now be described with reference to FIGS. 5a to 5c.

 In summary of what has been recalled in relation to a domain architecture, we see that each Dj domain has a structure that allows to identify and identify its software components: domain name, version number, file descriptive reference of the unitary components of the domain. This is the role played by the description 2 (Figure 2), more particularly records 20 (name and version of the domain) and 22 (description of the content of the domain), as well as the specific set of files containing the list of other files (names and version numbers).

As a practical example, the version number is associated with different structured indices which can be in the form of "vrm". "v" is a clue to the delivered version of the Dj domain. "r" is an index called "release", that is to say, provision. This index "r" indicates improved versions, but without major functional change. The index "m" is relative to the re-delivery of any element of the domain, functional or not. It is incremented on this occasion, usually from the value zero (initial state)
All these provisions allow to characterize the initial state of a particular domain Dj, with all its components, which is an advantage over other architectures.

 On the other hand, they do not allow to correctly follow the evolution of this particular domain Dj.

 Also, according to a first important feature of the invention, there is added to the existing structure an additional unitary component that will allow this tracking, which constitutes a subset of the domain.

 According to a second important characteristic of the invention, an additional index representative of the evolutions of the domain Dj, which will be called hereinafter "f" index and which relates to the correction lots of the domains, is used. This index can be advantageously numerical, which makes it possible to modify it simply by incrementation.

 FIG. 5a shows one of the domains present in the system 1 of FIG. 1: the domain Dj, of arbitrary index j. It is assumed that this is the initial state of the domain Dj, that is, the state in which it was delivered for its first installation on the system 1 (Figure 1).

 It is assumed that the domain Dj comprises N components of various types, referenced in Figure 5a "component 41" to "component &num; N". These components are associated with version indices that may be of various date structures, version numbers conforming to the above structure, to which a fourth index has been added (which leads to a structure similar to "vrmf") or any other version identification mode. For example, the version of the components "41" and "" &num; 2 "is identified by a structured sequence of the type" vrmf "(" 1.1.5.3 "and" 5.4.2.0 ", respectively), the component" # 3 "by a date and the components # 4" and "# 5" by simple numbers ("32.104" and "12", respectively). The component number "#N" by a mode not explicitly specified (referenced "<ident>"). In principle, there are no formal rules to identify the version of the components. Any identification methods that do not introduce ambiguity can be used.

 The set of components "component # 1" to "component #N", marked 4 in FIG. 5a, constitutes a software package whose evolution is to be followed over time, to guarantee consistency with a given reference. .

 In the case of a domain architecture, which constitutes a preferred architecture, the software set 4 can be likened to the part 3 (FIG. 2) of a domain Dj.

 We associate (link represented by a solid line 11) to the software set itself 4, a first component or subset 5 identifying this software set, for example the domain Dj. This component is an e "<domain name>" is an arbitrary domain name and "saga Id" a suffix to identify an object of type domain, and more generally belonging to a type of software entity determined.

 The version number 51 will advantageously have a similar structure to the structure "v.r.m.f" above. A priori, the fourth elementary index is equal to zero.

In the example shown, the version number of domain 51 is s3.2.1.0 ".

 A second component or subset 6 is associated with the software assembly 4, it is a component entirely specific to the invention. This component 6 is a record identifying the evolution of the software set 4. The structure of this component is similar to that of the component 5. It comprises a "name" part 60 and a "evolution version number" part 61 , the latter being in accordance with the aforementioned "vrmf" structure.

The main partial index, characteristic of this structure, is the supplementary index "f" indicating the number of the correction batch. The name part 60 makes it possible to link the recording to a given software set 4, in particular to a domain in the preferred application. It has the following structure: domain name>. <label> ", where" <domain-name, "is the name of the domain, and more generally the name of the software package, and" <label> "a suffix that identifies the additional component, that is, ie the type of registration 6.

 In principle, in the initial state, that is to say the state represented in FIG. 5a, the elementary index "f" (number of the correction batch) is equal to zero and the "version number d "evolution" 61 is identical to the domain version number 51, ie "3.2.1.0" in the illustrated example.

 Is represented under the reference 8, the current state of the machine, and more particularly the composition of each set of software 4. This current state comprises at least entries identifying the elementary components "component # 1" to "component #N ", as well as their version numbers. In the case of an architecture in domains, which constitutes the preferred architecture, if one refers again to FIG. 4, the current state of the machine is managed, a priori, by the operating monitor 13. an architecture other than the domain architecture, this state of the machine is managed by a similar entity or by the operating system.

 We will now illustrate the process of identifying and monitoring the corrections made to the components of the domain Dj, which has the arbitrary name of "domain name", with particular reference to the examples illustrated in FIGS. 5b and 5c. The number of the correction batch (current version) is indicated by the index f = 1 (case of the first version of correction batch figure 5b).

 First, it is assumed that the numbered components "# 3" and "45" are modified, that is, updated.

 The component "# 3", whose version identifier is a date (formerly "25/06/96" in the example described), has been updated. The date of the new version is "28/11/97".

 The component "# 5" whose version identifier is a simple version number (formerly "12") has also been updated and its new version number is "15".

The record 5 does not evolve, because the number and distribution of the components of the software package 4 have not been modified, only the versions of all or part of the components have been changed (in this case the components " 43 "and" 45 ")
By against the evolution identifier, that is to say the record identifying the corrections made to the software set 4, now referenced 6 '(with its two parts 60' and 61 '), will be set to day and in particular the index "f" supra (batch number of corrections) will be incremented by one unit. The evolution version number 61 'thus becomes "3.2.1.1", in the example described.

 According to a further feature of the invention, a given batch of corrections (indicated by the above-mentioned index ft) is accompanied by a file 7 ', or a series of records, which identifies the names of the components of the set of corrections made and their version.

 In addition, advantageously, each modification of the record 6 corresponds to a different file 7 ', which makes it possible to keep the history of the corrections made to the components of the software set 4, that is to say its evolution in time since its initial state (Figure 5a). These files will be referenced 7 '(Figure 5b), 7 "(Figure 5c), etc.

 A link 12 (solid line) symbolizes the update of the component 6 (and in particular of the part 61 ') and the creation of a file 7' associated with the component 6 '.

 In the case of the set of corrections of index f = 1, illustrated by FIG. 5b, the file 7 'comprises entries for the components &num; 3 and &num; 5, which alone have been modified with respect to the initial state of the software package 4. The updated components, &num; 3 and # 5, have their version identifier matched to the new state reached: a new version date for the component "#" and a new version number for component "45".

 At the new record 6 ', will also correspond to an update of the state 8' of the software set 4.

 FIG. 5c illustrates a new modification of all or part of the components of the software set 4 (correction set f = 2), in this case the "#lux" components and, again, the "# 5" component. component "# 1" changes from version number "1.1.5.3" to version number "1.2.0.0" and component "# 5" from version number "15" to version number "16".

 As before, the record 5 remains unchanged and retains the software set version number "3.1.2.0" in the example described.

 The record identifying the evolution becomes 6 "(with its two parts 60" and 61 "), the index" f "being incremented by one again, the evolution identifier number 61" becomes "3.2 .1.2 in the example described.

 Likewise, a new file 7 "is created which identifies the names of the components of the set of corrections (index f = 2) and their versions, in the case illustrated by FIG. 5c, the updated components being" # 1 " and "45", the file 7 "comprises entries for these two components, which alone have evolved compared to the previous modification (FIG. 5b: index f = 1).

 As previously, at the new record 6 ", will also correspond to an update of the state 8" of the software set 4.

 In summary, when installing a software package 4 (more particularly, in the preferred application, during the installation of a domain Dj), the additional component 6 according to the invention is implemented at the same time than this software package.

 Then, each coherent set of modifications (lots of corrections f = x, with x = 1, 2, etc.) is described in a set of files 7 ', 7 ", etc., each being attached to a new version of the component specific to the invention, that is, the 6 ', 6 "recordings, etc.

The files 7 ', 7 ", etc., include records with the names of the patch batch components and their versions.

 The first version of the changes is identified by a version upgrade number "v.r.m.l" (the initial version being "v.r.m.0") and the subsequent ones by incrementing "f" (f = 2, 3, 4, etc.).

 The on-site application of a coherent set of modifications (batch of corrections) on a system 1 (FIG. 1) is always accompanied by a new version of the record 6, and more particularly by the part 61 (the index "f" being incremented by one unit), which constitutes an electronic signature of the modification made.

 All the sets of changes are disjoint from each other: the "f + 1" version of a set of corrections does not contain the corrections from the previous version "f".

 Each set of corrections has its own set of descriptive files, 7 ', 7 ", etc. Thus the complete history of the various evolutions remains traced on the client site In other words, all the intermediate files remain available and make it possible to reconstitute the complete evolution of the software package.

 Finally, so far, it has been considered, at least implicitly, that the successive files 7 ', 7 ", etc. contained only information on the component names and the successive versions thereof.

 In a preferred variant of the invention, these files are advantageously supplemented by text mode files (not shown) documenting each of the modifications made to the components.

 The comparison operations of the current state, 8'or 8 ", of the software set 4 present on the system 1 (according to the level of evolution reached by the software set 4 and determined by the index" f " ) relative to the reference file attached to each new set of corrections (file corresponding to the index "f + 1") can be simplified by using specialized external management tools or internal to the system 1. In particular, these tools may advantageously be part of the specific domain 14, illustrated in FIG. 4, or service domain (insofar as this domain exists on the system 1). In a further variant, the operations may be left under the control of the domain basic, or operating system ("OS") 11 (Figure 1), which exists on any machine.

 The method according to the invention also makes it possible to follow the evolutions of a new domain (or, more generally, of a new software package). Indeed, the additional component 6 being linked to a particular domain, if one adds a domain, for example a domain Dp (with arbitrary p), this component 6 is implemented at the same time as the new domain Dp. It is considered to be an initial state and the index "f" takes the value zero when creating the domain Dp.

 In the eventual subsequent evolutions of the domain, the process detailed above is realized and it is useless to redefine it.

 Similarly, the deletion of any domain (or more generally of a software package), for example the aforementioned Dp domain, does not raise tracking problems either, for the same reasons. The additional component 6 being linked to this domain Dp, it disappears with this domain. However, the successive files 7 ', 7 ", etc., can remain recorded in the system 1, as history.

 In both cases, it is the operating monitor, that is to say the domain 13, for the domain architecture of FIG. 1 which completely identifies the entire system 1 and its basic components, that is, domains D1 to Dn.

 Finally, when the composition of one of the domains (or more generally of a software package), for example the domain Dj, is modified, not by simple correction or change of version of a component, but by adding or removal of one or more components, it is necessary to upgrade the domain version version number of domain 51, record 5.

 From the foregoing, it is easy to see that the invention achieves the goals it has set for itself.

 It should be clear, however, that the invention is not limited to the only examples of embodiments explicitly described, particularly in relation to FIGS. 5a to 5c.

 In particular, the numbering of component versions, domains and evolutions can be done in various ways. Only the elementary index, which has been arbitrarily called "f" directly relates to the method of the invention, because identifying the level of evolution of the corrections made to the components of the software package. It can, however, be replaced by a similar means for reflecting successive states, whether this means is purely software (byte, etc.) or hardware (incremented counter). Similarly, if it is customary to force the aforementioned index or its equivalent to zero to identify an initial state, this convention is purely arbitrary and other conventions can be adopted without departing from the scope of the invention. One could use the letters of the alphabet, instead of a numerical index or any other convention establishing a one-to-one relationship between the index used and the correction batch.

 It should also be clear that, although particularly suited to a system architecture in domains as defined in the present description, the invention can not be confined to this type of architecture alone. It applies to the tracking of any multicomponent software package.

Claims (11)

 A method for identifying and tracking changes in a set of software components determined (4) in an information processing system (1), each component (# 1 to #N) being identified by a name and a version identifier, and each set of software components (4) being linked (11) to a first subset (5) comprising an identifier (50, 51) of said software set and its version, characterized in that the modifications provided to all or some of said components (# 1 to #N) of a set of determined software components (4) are identified by a so-called correction set index, in that the determined set of software components (4) is associated with a second subset (6, 6 ', 6 ") comprising an identifier (60, 60', 60") of said determined set of software components (4) and said set of patches and a version identifier d evolution (61, 61, 61 "), this evolution version identifier (61, 61 ', 61") comprising at least least said correction lot index, and in that said second subset (6 ', 6 ") is linked (12) to at least a first sequence of records (7', 7") describing the component names said batch of corrections (# 3- # 5, # 1- # 5) and their versions.  2. Method according to claim 1, characterized in that, during the implementation of a new set of software components (4) on said information processing system (1), said second subset associated (6 ) is implanted at the same time as the latter, and in that, said correction batch index being a numerical index, the initial state of said set of determined software components (4) is identified by setting the zero value of this index.  3. Method according to claim 2, characterized in that said correction batch index is incremented by one unit when setting up a new batch of corrections modifying all or part of said software components (# 1 to #N ).  4. Method according to any one of the preceding claims, characterized in that, for each series of modifications of all or part of said software components (# 1 to #N) corresponding to a new batch of corrections, said version identifier of evolution (61, 61 ") of the latter is modified.  5. Method according to claim 4, characterized in that, for each series of modifications of all or part of said components (# 1 to #N) corresponding to a new batch of corrections, a new first series of recordings is created ( 7 ', 7 "), associated with said modified second subset (6', 6") and identifying said modified software components and their new versions, this new first series of recordings (7 ', 7 ") being disjoint versions preceding.  6. Method according to claim 5, characterized in that all said series of created records (7 ', 7g) remain stored on said information processing system (1), so as to constitute a history of correction batches successively applied to said determined set of software components (4).  7. Method according to any one of the preceding claims, characterized in that said first sequence of records (7 ', 7 ") is associated with a second series of records comprising informational data on said corrections applied by said batches of corrections.  8. Method according to any one of the preceding claims, characterized in that said identifier (60, 60 ', 60 ") of the determined set of software components (4) and the set of corrections of said second subset (6, 6 ', 6 ") is structured as <name>. <label>, structure in which <name> identifies the name of said set of software components (4) and labels a suffix indicating the membership of said second subset (6 ') to a given type of software entity.  9. Method according to any one of the preceding claims, characterized in that said evolution version number comprises a version number of said determined set of software components (4) supplemented by said correction batch index.  10. Method according to any one of the preceding claims, characterized in that said sets of software components (4) consist of so-called domain entities (Dj) each comprising at least one of said software components, in that each domain (11) -14) contains a subset said descriptor (2) giving access to specific information determined (20-22), said information comprising at least one identifier (20) of the domain and data (22) describing said components, the installing and / or updating said domains (11-14) being performed from predetermined rules and said specific determined information (20-22), and in that said second subsets (6 ', 6 ") identify said domains (Dj) to which they are linked and the version of the current batch of corrections applied to these domains (Dj).  11. The method of claim 10, characterized in that said identifier (20) comprises at least domain name and version information (Dj).