Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F8/00—Arrangements for software engineering
  • G06F8/70—Software maintenance or management
  • G06F8/71—Version control; Configuration management

Definitions

• the present invention relates to a method for identifying and monitoring the development of a set of software components.
• a software product is usually made up of a set of unitary components perfectly identified by a series of information, such as the creation date, stamp of the version type, etc., which makes it possible to follow their evolution.
• the method of the invention relates more particularly to systems of this type and we will briefly recall the main characteristics.
• a first architecture belongs to the so-called "owner" type. Under this term, we mean systems whose architecture is designed by the hardware manufacturer.
• the architecture is essentially characterized by extensive integration and takes the form of a monolithic system.
• a second architecture belongs to the so-called "open” type. Under this term, we mean systems whose architecture is not defined by a single manufacturer. These systems appeared, in particular, with the emergence of operating systems of the "UNIX” (registered trademark) or similar type, for example "AIX” (registered trademark).
• - compatibility ie being able to count on a guarantee of upward compatibility of products and interfaces between products
• updating during the current operation of the system that is to say being able to change version of a product without stopping operation or, at least, with a minimum stopping
• - backtracking that is to say the possibility of reverting to an earlier version of a product in the event of a problem, without stopping 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
• speed of developments and maintenance that is to say being able to count on a minimum delay between a request for changes or correction, and its effective installation on site.
• the information processing system presents an architecture in domains.
• a domain is defined as gathering a set of functionalities offered by software components of the system. 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.
• FIG. 1 schematically illustrates such an architecture called "domains".
• the system 1 comprises a hardware platform 10.
• the set of software and software packages is divided into domains, 11 to 13. More particularly, there is a set of domains, Di, D2, ..., Oj,. . . , ⁇ n , grouped under the general reference 12, and two specific fields, 11 and 13. These last two fields are, respectively, the field 11 providing the operating system (or "OS") and the associated basic software of the system, and domain 13 providing the operating monitor for system 1.
• System 1 therefore includes at least these two domains, 11 and 13, in addition to the hardware platform 10. This is the version of domain 13, system operating monitor, which completely identifies the entire system 1 and its basic components, that is to say the different areas and the functionalities they offer.
• indices j and n identifying the domains are purely arbitrary, j being an intermediate index and n the maximum number of domains (not including the specific domains 11 and 13), at least in a given configuration state of the system.
• the other fields, 12, are optional and are selected by the user according to his precise needs and the application considered.
• These domains can be called “trivialized domains”, in the sense that they are “seen” in a similar way by the system, even if their content is different.
• System 1 is therefore entirely modular at the domain level.
• system administration functions can be implemented in the system: system administration functions, batch processing functions, database management functions, security function, transaction process management functions and interoperability.
• a determined system 1 meeting the needs of the user, is installed in a given state. In other words, the configuration and the versions of the domains are precisely defined.
• 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.
• the architectures according to 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 reference qualified.
• the architecture in domains makes it possible to properly characterize the initial state of a domain, that is to say of a software package comprising several components, but does not allow the identification and monitoring of the evolutions of this software package.
• the invention aims to overcome the drawbacks of the methods of the known art.
• the method according to the invention consists in providing a structure authorizing the management and monitoring of the evolution of a coherent software package.
• This structure comprises a unitary component consisting of a record linked to the aforementioned software package and perfectly identifiable by the system, the configuration of which will be detailed below.
• This component includes in particular a set of files authorizing the monitoring of changes and a reference file containing the unit identifications of each modified component.
• the subject of the invention is therefore a method of identifying and monitoring the development of 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 of its version, characterized in that the modifications made to all or part of said components of a given set of software components are identified by a so-called index set of corrections, in that the determined set of software components is associated with a second subset comprising an identifier of said set of determined software components and of said set of corrections and an identifier of evolution version, this identifier evolution version comprising at least said correction batch index, and in that said second subset is linked at least a first series of records describing the names of the components of said batch of corrections and their versions.
• FIG. 1 schematically illustrates an architecture of a system for processing information in domains
• - Figure 2 schematically illustrates the structure of a domain, basic building block of the architecture of Figure 1
• FIG. 3 illustrates an example of hierarchical organization of the domains
• - Figure 4 illustrates a particular area and its relationships with other areas of the system;
• DJ domain As an independent unit for integration, installation and updating. It includes one or more software or software packages from various sources: internal or external, which will be called products.
• internal or external which will be called products.
• internal is meant “owner” type applications.
• external is meant applications available on the market.
• an area has two main parts.
• a first part 3 consists of the various products offering functionalities specific to a domain, identified 30 to 32.
• a batch processing domain will offer at least the following functions: management of printing and backups.
• the second part 2 constitutes a particular interface of the Dj domain, which can be called
• Dj domains The functionalities provided by the Dj domains are supported by products which are characterized, among others, by the way they are integrated into system 1, by the way they install and run, and by the other products (i.e. other domains) on which they eventually depend.
• Part 2 or descriptor must therefore give access to information characterizing a particular DJ domain, in particular to an identifier concerning its name and version, and to a list of its components.
• a DJ domain is characterized by a number of attributes, as indicated. All this information is necessary to be able to carry out the basic operations mentioned above: installation and update of the domains. They also describe the operating mode of the products making up the domain.
• the domain is organized according to a hierarchy of objects.
• the first level is the product P itself.
• the product consists of a set of modules
• M ⁇ to Mi3 three in the example described in Figure 3 or "packages", which constitute the second hierarchical level.
• the second level therefore groups the modules M ⁇ to
• a module M ⁇ to M 3 is a homogeneous functional subset of a product Pi. It consists of a set of file sets or "filesets" FS ⁇ , FS 2 and FSi3i and FSi 3 2 (in the example described in Figure 3).
• .NVe external visibility
• a fileset 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 M ⁇ and Mi2, can comprise only one set of files, FS ⁇ and FSi2 respectively.
• a module can include two or more sets of files. This is the case of the i3 module which includes two sets of files, FSi3i and FSi32 •
• the fourth level consists of the files themselves, Fin, Fil2, i21,? I22, Fi3i, Fi32l and Fi322-
• Each set of files can include one or more files.
• the third and fourth levels constitute a level of internal visibility ISTVi, not visible by the user in normal use. However, the updates concern 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, one also specific file containing the list, that is to say the name and the version number, of all the other sets of files of the domain Dj. In addition to its role as a container, this particular file is used to ensure the consistency of the Dj domain. Indeed, all the other sets of files in the Dj domain are declared dependent on the specific set of files. The installation or the update of any set of files, belonging to the Dj domain, is only possible if the version of the domain allows it, at least as far as controlled or integrated products are concerned. that is, a sufficiently high level of insertion.
• system 1 can comprise a third specific domain, 14, which can be called service domain or "tools" domain.
• This domain includes, in particular, software products or utilities, also specific, allowing the installation and / or the update of all or part of the domains, Di to O n , and in each domain, of all or part of the products , whether they are of internal origin, that is to say a priori fully integrated into the domains, or external, these external products being controlled or not, depending on the level of insertion associated with the domain.
• the tools, or "engines”, for installation and updating present in this domain are in interaction with the domains, Di to D n , as well as with the basic domain 11, and the monitor domain. e.xploitation 13, and more particularly with their descriptor sets 2.
• the installations are carried out according to rules recorded in field 14 and / or descriptor sets 2.
• each domain Dj includes a specific set of files containing the list of the other sets of files, that is to say at least their names and their version numbers. We can also supplement this information with scripts and rules for installing and updating products external to the domain.
• each Dj domain has a structure which makes it possible to identify and identify its software components: domain name, version number, file of descriptive reference of the unitary components of the domain. This is the role played by 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).
• the version number is associated with different structured indices which can appear in the following form: "vrm”.
• "v” is an index concerning the delivered version of the Dj domain.
• “r” is a so-called “release” index, that is to say of availability. This index “r” indicates improved versions, but without major functional change.
• the index “m” relates to the re-delivery of any element of the domain, functional or not. It is incremented on this occasion, generally from the value zero (initial state).
• an additional unitary component is added to the existing structure which will allow this monitoring, which constitutes a subset of the field.
• index "f" an additional index representative of the developments in the domain Dj is used, which will hereinafter be called index "f" and which relates to the correction batches of the domains.
• This index can advantageously be numeric, which makes it possible to modify it simply by incrementation.
• the domain Dj of arbitrary index j. It is assumed that this is the initial state of the domain Dj, that is to say 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 natures, referenced in FIG. 5a "component # 1" to "component #N". These components are associated with version indices which can be of various structures: date, version numbers conforming to the above structure, to which a fourth index has been added (which leads to a structure similar to "vrmf”) or all other version identification mode.
• the version of components "# 1" and “# 2" is identified by a structured suite 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 >”).
• a priori there are no formal rules for identifying the version of the components. Any identification method that does not introduce ambiguity can be used.
• component #N identified 4 in FIG. 5a, constitutes a software assembly whose evolution over time is to be followed, in order to guarantee its consistency with respect to a given reference.
• the software assembly 4 can be assimilated to part 3 (FIG. 2) of a domain Dj.
• This component is a record comprising two parts: a "name” part 50, and a "domain version number or identifier" part 51 (and, more generally, software package).
• the name 50 can have the following composite structure " ⁇ domain_name>.saga_Id", in which " ⁇ domain_name>” is an arbitrary domain name and "saga_Id" is a suffix allowing to identify an object of type domain, and more generally belonging to a specific type of software entity.
• the version number 51 will advantageously have a structure similar to the above-mentioned structure "v.r.m.f".
• a pri ori the fourth elementary index is equal to zero.
• the domain version number 51 is "3.2.1.0".
• a second component or sub-assembly 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 assembly 4.
• the structure of this component is similar to that of component 5. It includes a "name” part 60 and a “evolution version number” part 61 , the latter being in accordance with the above-mentioned "vrmf" structure.
• the main partial index, characteristic of this structure, is the additional index "f” indicating the number of the correction lot.
• 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>", in which " ⁇ domain_name>" is the name of the domain, and more generally the name of the software package, and " ⁇ label>" a suffix that allows identify the additional component, i.e. record type 6.
• the elementary index "f" (number of the correction lot) 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 example illustrated.
• the current state of the machine and more particularly of the composition of each software set 4.
• This current state includes at least entries identifying the elementary components: "component # 1" to "component #N”, as well as their version numbers.
• the current state of the machine is managed, a priori, by the operating monitor 13.
• this state of the machine is managed by a similar entity or by the operating system.
• the date of the new version is as follows: "11/28/97”.
• Record 5 does not change because the number and distribution of the components of software package 4 have not been changed, only the versions of all or part of the components have been changed (in this case the components "# 3 "and”# 5 ").
• the evolution identifier that is to say the recording identifying the corrections made to the software package 4, now referenced 6 '(with its two parts 60' and 61 '), will be set to day and in particular the aforementioned index "f" (batch number of corrections) will be incremented by one.
• the evolution version number 61 'therefore becomes "3.2.1.1", in the example described.
• a given batch of corrections (identified by the aforementioned index "f") is accompanied by a 7 'file, or series of records, which identifies the names of the components of the batch of corrections. brought and their version.
• 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 package 4, that is to say its evolution over time since its initial state ( Figure 5a).
• These files will be referenced 7 '( Figure 5b), 7 "( Figure 5c), etc.
• a link 12 symbolizes the updating of component 6 (and in particular of part 61 ') and the creation of a file 7' associated with component 6 '.
• the updated components, # 3 and # 5, have their version identifier matched to the new state reached: a new version date for component "# 3" and a new version number for the component "# 5".
• Component “# 1” goes 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".
• the evolution identifier record becomes 6 "(with its two parts 60" and 61 "), the index" f "being again incremented by one.
• the evolution identifier number 61" becomes "3.2 .1.2 "in the example described.
• the additional component 6 according to the invention is implemented at the same time than this software package.
• Each set of corrections has its own set of descriptive files, 7 ', 7 ", etc.
• the complete history of the various changes remains traced on the client site.
• all the intermediate files remain available and make it possible to reconstruct the complete evolution of the software package.
• these files are advantageously supplemented by files in text mode (not shown) documenting each of the modifications made to the components.
• the operations for comparing the current state, 8 ′ or 8 ′′, of the software assembly 4 present on the system 1 (according to the level of evolution reached by the software assembly 4 and determined by the index "f" ) compared to the reference file attached to each new set of corrections (file corresponding to the index "f + 1") can be simplified by using specialized administrative tools external or internal to the system 1.
• these tools can advantageously be part of the specific domain 14, illustrated by FIG. 4, or service domain (insofar as this domain exists on the system 1).
• the operations can be left under the control of the base domain, or operating system ("OS") 11 ( Figure 1), which exists on any machine.
• OS operating system
• 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 a domain is added, for example a domain D (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 during the creation of the domain Dp.
• any domain (or more generally of a software package), for example the aforementioned domain Dp, does not pose any monitoring problems either, always for the same reasons.
• the additional component 6 being linked to this domain Dp, it disappears with this domain.
• successive files 7 ′, 7 ′′, etc. can remain saved in system 1, for 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 to say the domains Di to O n .
• composition of one of the domains (or more generally of a software package), for example the Dj domain, is modified, not by simple correction or change of version of a component, but by addition or deletion of one or more components, it is necessary to update the domain version: domain version number 51, of record 5.
• the numbering of the versions of the components, the domains and the evolutions can be carried out in various ways. Only the elementary index, which has been called arbitrarily "f" directly concerns the method of the invention, since it identifies the level of evolution of the corrections made to the components of the software assembly. It can however be replaced by a similar means making it possible to reflect successive states, whether this means is purely software (byte, etc.) or hardware (counter incremented). Similarly, if it is customary to force the aforementioned index or its equivalent to the value 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.

Landscapes

• Engineering & Computer Science (AREA)
• Software Systems (AREA)
• General Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Stored Programmes (AREA)

Applications Claiming Priority (3)

Publications (1)

Family

ID=9515296

Family Applications (1)

Country Status (3)

Families Citing this family (5)

Family Cites Families (2)

• 1997
  • 1997-12-30 FR FR9716700A patent/FR2773242A1/fr active Pending
• 1998
  • 1998-12-28 EP EP98963637A patent/EP0961969A1/de not_active Withdrawn
  • 1998-12-28 WO PCT/FR1998/002887 patent/WO1999035566A1/fr not_active Application Discontinuation

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events