WO1999035566A1 - Procede d'identification et de suivi des evolutions d'un ensemble de composants logiciels - Google Patents

Procede d'identification et de suivi des evolutions d'un ensemble de composants logiciels Download PDF

Info

Publication number
WO1999035566A1
WO1999035566A1 PCT/FR1998/002887 FR9802887W WO9935566A1 WO 1999035566 A1 WO1999035566 A1 WO 1999035566A1 FR 9802887 W FR9802887 W FR 9802887W WO 9935566 A1 WO9935566 A1 WO 9935566A1
Authority
WO
WIPO (PCT)
Prior art keywords
software components
domain
version
components
corrections
Prior art date
Application number
PCT/FR1998/002887
Other languages
English (en)
Inventor
Denis Chauvalon
Bernard Cheval
Amélie DE MONES DEL PUJOL
Original Assignee
Bull S.A.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bull S.A. filed Critical Bull S.A.
Priority to EP98963637A priority Critical patent/EP0961969A1/fr
Publication of WO1999035566A1 publication Critical patent/WO1999035566A1/fr

Links

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)

Abstract

L'invention concerne un procédé d'identification et de suivi des évolutions d'un ensemble de composants logiciels (4), chaque composant (#1 à #N) étant repérés par un nom et un identifiant de version, et chaque ensemble de composants logiciels (4) étant lié à un premier sous-ensemble (5) comprenant un identifiant (50, 51) de l'ensemble logiciel et de sa version. Les modifications apportées aux composants logiciels (#1 à #N) sont repérées par un indice de lot de corrections qui est incrémenté lors de l'application d'un nouveau lot de corrections. On prévoit un second sous-ensemble (6) comprenant un identifiant (60) de l'ensemble de composants logiciels (4) et du lot de corrections, et d'un numéro de version d'évolution (61) comprenant au moins l'indice de lot de corrections. Ce second sous-ensemble (6) est associé (12) à un fichier (7') décrivant les noms des composants logiciels (#3, #5) du lot de corrections et leurs versions.

Description

PROCEDE D'IDENTIFICATION ET DE SUIVI DES EVOLUTIONS D'UN ENSEMBLE DE COMPOSANTS LOGICIELS
La présente invention concerne un procédé d'identification et de suivi des évolutions d'un ensemble de composants logiciels.
Un produit logiciel est habituellement formé d'un ensemble de composants unitaires parfaitement identifiés par une série d'informations, telles que la date de création, estampille du type de version, etc., ce qui permet de suivre leurs évolutions.
Cependant il n'existe généralement pas d'identification non ambiguë portant sur le produit logiciel considéré dans sa globalité et permettant de suivre 1 ' évolution de chacun de ses composants .
En outre, lorsqu'on s'intéresse à une solution logicielle qui est composée d'un ensemble de produits logiciels, qui plus est peuvent être hétérogènes et multi- fournisseurs, il n'existe aucun moyen d'identifier globalement cet ensemble, ni surtout de suivre son évolution.
Or, la maîtrise de l'état de chaque composant unitaire d'une solution logicielle, qui consiste à s'assurer qu'il se trouve bien à un niveau donné (c'est-à-dire à une version donnée) , est le seul moyen de garantir son intégrité.
Ce problème se pose déjà avec une certaine acuité pour les petits systèmes (micro-ordinateurs) et les systèmes moyens ("mini-ordinateurs ou ordinateurs dits "départementaux"), ce d'autant plus que la puissance de ces systèmes augmentent régulièrement . On conçoit aisément que le problème évoqué se pose avec encore plus d'acuité pour les très gros systèmes ou "mainframe", selon la terminologie anglo-saxonne .
Aussi, le procédé de l'invention concerne plus particulièrement les systèmes de ce type et on va en rappeler brièvement les caractéristiques principales.
Ces systèmes, très complexes, intègrent de très nombreux sous-systèmes, tant matériels que logiciels qui coopèrent entre eux. Il n'est pas rare que des produits logiciels constituants de ces systèmes, comportent des centaines de milliers, voire des millions de lignes de code.
Dans ce contexte, un des problèmes les plus difficiles à résoudre est d'obtenir la cohérence et la compatibilité entre les différents composants, notamment lorsqu'ils doivent être mis à jour (passage à des versions plus récentes, ajout de modules ou de fonctions, etc.) .
En effet, outre la complexité intrinsèque rappelée, on doit également tenir compte du fait que les différents produits composant le système ont des provenances disparates, que ce soit en interne (même si des règles de développement communes sont en vigueur) ou en externe
(produits disponibles sur le marché) .
Dans l'état de la technique, il existe deux types principaux d'architectures.
Une première architecture appartient au type dit "propriétaire". Sous ce vocable, on désigne des systèmes dont l'architecture est conçue par le constructeur de matériel informatique.
L'architecture se caractérise essentiellement par une intégration poussée et se présente sous la forme d'un système monolithique.
Dans ce système, tous les composants de l'ensemble sont pris en compte lors de l'installation initiale et lors des mises à jour ultérieures (changement de version du système) . Dans ce type d'environnement, la cohérence du système est obtenue par la validation globale des interfaces entre tous les composants. Pour l'utilisateur, ces dispositions garantissent une grande robustesse du système indépendamment de ses évolutions. En outre, elles permettent un suivi simplifié des versions successives du système. Enfin, elles assurent une disponibilité maximale et une grande sécurité de fonctionnement, puisque les risques de dysfonctionnement sont réduits au minimum.
Cependant, il existe en contrepartie des contraintes et des inconvénients sérieux.
Ceux-ci trouvent leur origine dans le fait que les systèmes sont monolithiques . Quel que soit le composant à changer et/ou la fonction à ajouter, il est nécessaire de faire évoluer tout le système. La mise à jour ne peut être que globale.
Enfin, la mise à jour entraîne une indisponibilité importante du système de traitement de données, couramment plusieurs jours pour de très gros systèmes.
Il s'ensuit que ce type d'architecture a relativement peu de souplesse et présente des possibilités d'évolution limitées.
Une seconde architecture appartient au type dit "ouvert". Sous ce vocable, on désigne des systèmes dont l'architecture n'est pas définie par un seul constructeur. Ces systèmes sont apparus, notamment, avec l'émergence des systèmes d'exploitation du type "UNIX" (marque déposée) ou similaires, par exemple "AIX" (marque déposée) .
II est clair que ce type d'architecture est très attractif, car il permet de faire appel à des logiciels hétérogènes, c'est-à-dire d'origines diverses, coexistant sur une même machine . Pour ce type d'architecture, l'installation et/ou la mise à jour d'un logiciel ne concernent que le produit lui- même, et non le système dans sa globalité.
Puisque des composants de base peuvent être installés ou mis à jour à tout moment, une architecture "ouverte" offre donc une très grande souplesse et des facilités d'évolution importantes, du moins en théorie.
En effet, ce type d'architecture n'est pas non plus exempt d'inconvénients. En particulier, il n'offre aucune garantie de bon fonctionnement avec les autres composants logiciels : possibilités d'incompatibilité diverses, etc.
Or, malgré les inconvénients qui lui sont inhérents, un système à architecture ouverte reste très séduisant pour les utilisateurs.
En effet, il permet de satisfaire, tout ou partie, des besoins des utilisateurs de systèmes informatiques qui se font actuellement sentir, parmi lesquels : autonomie, c'est-à-dire la possibilité de faire évoluer un ou plusieurs produits du système, indépendamment du reste du système ;
- parallélisme, c'est-à-dire la possibilité de faire tourner plusieurs versions du même produit simultanément ;
- compatibilité, c'est-à-dire pouvoir compter sur une garantie de compatibilité ascendante des produits et des interfaces entre produits ; mise à jour pendant 1 ' e.xploitation courante du système, c'est-à-dire pouvoir changer de version d'un produit sans arrêt de l'exploitation ou, pour le moins, avec un arrêt minimum ; - retour en arrière, c'est-à-dire la possibilité de revenir à une version antérieure d'un produit en cas de problème, sans arrêt de l'exploitation ; - maîtrise des évolutions, c'est-à-dire la possibilité de rester maître du processus d'évolution par la mise en oeuvre de procédures automatisées et simplifiées ; et rapidité des évolutions et de la maintenance, c'est-à-dire pouvoir compter sur un délai minimum entre une demande d'évolution ou de correction, et son installation effective sur site.
Pour pallier les inconvénients des deux types d'architectures précités, tout en conservant les avantages de chacun, la Demanderesse a proposé, dans une demande de brevet français N° 97 08332, déposée le 2 juillet 1997 et intitulée "Architecture de système de traitement de l'information", une solution visant à répondre pleinement aux besoins des utilisateurs qui viennent d'être rappelés.
Pour ce faire, le système de traitement de 1 ' information présente une architecture en domaines .
Un domaine est défini comme regroupant un ensemble de fonctionnalités offertes par des composants logiciels du système. Il a des caractéristiques propres et évolue de façon indépendante. Le système est alors composé d'un ensemble de domaines ayant un minimum d'interdépendances, ce qui garantit la cohérence globale.
En d'autres termes, la souplesse d'installation et la mise à jour sont introduites à un niveau macroscopique qui reste maîtrisable, c'est-à-dire le domaine au sein duquel la cohérence reste assurée.
Chaque domaine, quel qu'il soit, est "vu" de façon identique par l'utilisateur, grâce notamment à des attributs qui lui sont affectés et un descripteur.
La figure 1 annexée à la présente description illustre schématiquement une telle architecture dite en "domaines" . Le système 1 comprend une plate-forme matérielle 10. Selon une caractéristique importante de la demande de brevet précitée, l'ensemble des logiciels et progiciels est scindé en domaines, 11 à 13. De façon plus particulière, il existe un ensemble de domaines, Di, D2, ..., Oj , . . . , Ωn, regroupés sous la référence générale 12, et deux domaines spécifiques, 11 et 13. Ces deux derniers domaines sont, respectivement, le domaine 11 fournissant le système d'exploitation (ou "OS") et les logiciels de base associés du système, et le domaine 13 fournissant le moniteur d' exploitation du système 1. Le système 1 comprend donc au minimum ces deux domaines, 11 et 13, en sus de la plate-forme matérielle 10. C'est la version du domaine 13, moniteur d'exploitation du système, qui identifie complètement l'ensemble du système 1 et de ses composants de base, c'est-à-dire les différents domaines et les fonctionnalités qu'ils offrent.
Les indices j et n repérant les domaines sont purement arbitraires, j étant un indice intermédiaire et n le nombre maximal de domaines (non compris les domaines spécifiques 11 et 13) , du moins dans un état de configuration donné du système.
Les autres domaines, 12, sont optionnels et sont sélectionnés par l'utilisateur en fonction de ses besoins précis et de l'application considérée. On peut appeler ces domaines "domaines banalisés", en ce sens qu'ils sont "vus" de façon semblable par le système, même si leur contenu est différent. Le système 1 est donc entièrement modulaire au niveau des domaines .
Pour fixer les idées, les domaines suivants peuvent être implémentés dans le système : fonctions d'administration du système, fonctions de traitement par lots, fonctions de gestion de bases de données, fonction de sécurité, fonctions de gestion des processus transactionnels et fonctions d'interopérabilité. Un système déterminé 1, répondant aux besoins de l'utilisateur, est installé dans un état donné. En d'autres termes, la configuration et les versions des domaines sont précisément définies.
Cette installation peut être obtenue de deux façons :
Il s'agit tout d'abord de l'installation initiale proprement dite, que l'on peut appeler "clés en mains", c'est-à-dire d'une pré-configuration réalisée en usine. - Il peut s'agir aussi d'une mise à jour incrémentale de la machine sur site d'exploitation. Les mises à jour concernent alors un ou plusieurs domaines, selon les besoins. Mais il n'est jamais nécessaire, contrairement aux systèmes de type "propriétaire" de l'art connu, de modifier tout le système 1.
Il existe en réalité deux types principaux de mise à jour :
- La mise à jour proprement dite (ou "update" selon la terminologie anglo-saxonne) : un domaine donné, Oj , ayant fait l'objet d'une installation initiale, il s'agit d'en installer une version plus récente pour y incorporer, soit des nouvelles fonctionnalités, soit des corrections. Cette opération entraîne notamment le changement de la version du domaine . - Ajout (ou "add-on" selon la terminologie anglo- saxonne) : il s'agit de l'ajout pur et simple d'un domaine particulier, par exemple On, qui n'avait pas été installé initialement .
Il doit être clair également que un ou plusieurs domaines peu(ven)t être supprimé (s).
Tous les domaines, 11 à 13, coopèrent avec la plateforme matérielle 10, directement ou via le domaine de base ou système 11. De même, tous les domaines "banalisés" 12 coopèrent avec les domaines spécifiques, 11 et 13. Des liens verticaux (sur la figure 1) illustrent ce mode de fonctionnement .
Il est avantageux que les domaines 12 présentent la plus grande indépendance les uns vis-à-vis des autres. En d'autres termes, il est important que les interactions entre ces domaines soient minimisées. Généralement, il existe cependant des relations entre certains des domaines Di à On . Ces relations ont été figurées par des liens horizontaux (sur la figure 1) .
Bien que le nombre de domaines ne soit pas, a pri ori , limité, dans la pratique, le nombre raisonnable de domaines est préférentiellement inférieur à dix et, en tout cas, devrait se situer dans la gamme de dix à vingt au maximu .
Dans le cas contraire, la complexité augmente de façon très importante : fonction en x(x-l)/2, avec x nombre total de domaines . Les avantages apportés par 1 ' architecture selon l'invention s'en trouvent alors largement amoindris.
En résumé, l'architecture en domaines qui vient d'être rappelée permet de cumuler les avantages des architectures de type "propriétaire" et de type "ouvert" : robustesse, disponibilité, sécurité, souplesse et évolutivité.
Elle présente donc de nombreux avantages, mais il subsiste cependant un inconvénient qui va être explicité ci- après .
Comme il a été précédemment indiqué, les architectures selon l'art connu ne permettent, pour la plupart, que la seule identification de chaque composant unitaire, ce qui rend très difficile de suivre son évolution et de connaître son état par rapport à une référence dûment qualifiée. Par contre, l'architecture en domaines permet de bien caractériser l'état initial d'un domaine, c'est-à-dire d'un ensemble logiciel comprenant plusieurs composants, mais ne permet pas l'identification et le suivi des évolutions de cet ensemble logiciel.
En cela, malgré ses avantages certains, 1 ' architecture en domaines laisse donc subsister un inconvénient commun aux autres architectures .
L'invention vise à pallier les inconvénients des procédés de l'art connu.
Elle se fixe pour buts : d'identifier l'état d'un ensemble de produits logiciels ; de vérifier la cohérence de cet ensemble par rapport à une référence ; et de suivre l'évolution de cet ensemble.
Pour ce faire, le procédé selon l'invention consiste à prévoir une structure autorisant la gestion et le suivi de l'évolution d'un ensemble logiciel cohérent.
Cette structure comprend un composant unitaire consistant en un enregistrement lié à l'ensemble logiciel précité et parfaitement identifiable par le système, dont la configuration sera détaillée ci-après. On rattache notamment à ce composant un ensemble de fichiers autorisant le suivi des évolutions et un fichier de référence contenant les identifications unitaires de chaque composant modifié.
Bien que le procédé selon 1 ' invention s ' applique de façon préférentielle à une architecture en domaines telle qu'elle vient d'être rappelée, il ne saurait être limité à ce seul type d'architecture. Cependant, pour fixer les idées, le procédé de l'invention sera décrit ci-après dans le cadre de cette application préférée, sauf mention contraire.
L'invention a donc pour objet un procédé d'identification et de suivi des évolutions d'un ensemble de composants logiciels déterminé dans un système de traitement de l'information, chaque composant étant repéré par un nom et un identifiant de version, et chaque ensemble de composants logiciels étant lié à un premier sous-ensemble comprenant un identifiant dudit ensemble logiciel et de sa version, caractérisé en ce que les modifications apportées à tout ou partie desdits composants d'un ensemble de composants logiciels déterminé sont repérées par un indice dit de lot de corrections, en ce que l'ensemble de composants logiciels déterminé est associé à un second sous- ensemble comprenant un identifiant dudit ensemble de composants logiciel déterminé et dudit lot de corrections et d'un identifiant de version d'évolution, cet identifiant de version d'évolution comprenant au moins ledit indice de lot de correction, et en ce que ledit second sous-ensemble est lié à au moins une première suite d'enregistrements décrivant les noms des composants dudit lot de corrections et leurs versions.
L'invention sera mieux comprise et d'autres caractéristiques et avantages apparaîtront à la lecture de la description qui suit en référence aux figures annexées, parmi lesquelles :
- la figure 1 illustre schématiquement une architecture de système de traitement de 1 ' information en domaines ; - la figure 2 illustre schématiquement la structure d'un domaine, élément constitutif de base de l'architecture de la figure 1 ; la figure 3 illustre un exemple d'organisation hiérarchique des domaines ; - la figure 4 illustre un domaine particulier et ses relations avec les autres domaines du système ;
- les figures 5a à 5c illustrent schématiquement le procédé conforme à l'invention.
Le procédé selon l'invention va être décrit, comme il a été indiqué dans le cadre de l'application préférée de l'invention, c'est-à-dire dans le cadre d'un système de traitement de 1 ' information à architecture en domaines .
Aussi, il apparaît tout d'abord utile de décrire, de façon plus détaillée, par référence à la figure 2, une unité élémentaire que constitue un domaine, Oj , d'indice arbitraire j .
On peut définir un domaine Dj comme étant une unité indépendante d'intégration, d'installation et de mise à jour. Elle comprend un ou plusieurs logiciels ou progiciels de provenances diverses : interne ou externe, que l'on appellera produits. Par "interne", on entend des applications de type "propriétaire". Par "externe", on entend des applications disponibles sur le marché.
De façon plus précise, un domaine comprend deux parties principales.
Une première partie 3 est constituée des différents produits offrant des fonctionnalités propres à un domaine, repérées 30 à 32. A titre d'exemple, un domaine de traitement par lot offrira au moins les fonctions suivantes : gestions des impressions et des sauvegardes.
La seconde partie 2 constitue une interface particulière du domaine Dj, que l'on peut appeler
"descripteur" qui donne accès à des données décrivant le domaine et ses propriétés .
Les fonctionnalités fournies par les domaines Dj sont supportées par des produits qui se caractérisent, entre autres, par la manière dont ils sont intégrés dans le système 1, par la façon dont ils s'installent et s'exécutent et par les autres produits (c'est-à-dire les autres domaines) dont ils dépendent éventuellement.
La partie 2 ou descripteur doit donc donner accès à des informations caractérisant un domaine particulier Dj, notamment à un identifiant concernant son nom et sa version, et à une liste de ses composants. En outre, un domaine Dj est caractérisé par un certain nombre d'attributs, comme il a été indiqué. Toutes ces informations sont nécessaires pour pouvoir réaliser les opérations de base susmentionnées : installation et mise à jour des domaines. Elles décrivent aussi le mode de fonctionnement des produits composant le domaine .
Dans un mode de réalisation préféré, les attributs sont au nombre de trois, à savoir le niveau d'insertion, le type d'occurrence et les dépendances.
On va maintenant décrire de façon détaillée un exemple d'organisation pratique d'un domaine Dj, par référence à la figure 3.
Dans cet exemple pratique, le domaine est organisé selon une hiérarchie d'objets.
On va considérer ci-après, pour des raisons de simplification, un domaine Dj ne contenant qu'un seul produit Pi, étant entendu que ces dispositions s'appliquent tout aussi bien à des domaines comprenant plusieurs produits. Il est en effet clair que la structure de base d'un domaine est le produit, un domaine comprenant un ou plusieurs produits.
On peut cependant distinguer une structure hiérarchique à quatre niveaux, dans un mode de réalisation avantageux. Le premier niveau est le produit P proprement dit .
C'est un ensemble homogène offrant une fonctionnalité donnée. Le produit est constitué d'un ensemble de modules
Mϋ à Mi3 (trois dans l'exemple décrit sur la figure 3) ou "packages", qui constituent le deuxième niveau hiérarchique.
Le deuxième niveau regroupe donc les modules Mϋ à
Mj3. Un module Mϋ à M 3, est un sous-ensemble fonctionnel homogène d'un produit Pi. Il est constitué d'un ensemble de jeux de fichiers ou "filesets" FSϋ, FS 2 et FSi3i et FSi32 (dans l'exemple décrit sur la figure 3) .
Ces deux niveaux constituent un premier niveau de visibilité externe, .NVe, c'est-à-dire "visible" par l'utilisateur pour une mise à jour du domaine Dj et/ou son installation initiale.
il est ainsi possible d'installer tout ou partie des produits d'un domaine Dj , ainsi que tout ou partie des modules les composant, en tenant compte naturellement de contraintes de cohérence liées à ces produits.
Le troisième niveau regroupe les jeux de fichiers FSϋ, FSi2 et FSi3i et FSi32- Un jeu de fichiers est un ensemble de fichiers contribuant à la réalisation de tout ou partie des fonctionnalités offertes par un module. Un module, par exemple les modules Mϋ et Mi2, peut ne comprendre qu'un seul jeu de fichiers, FSϋ et FSi2 respectivement. Au contraire, un module peut comprendre deux jeux de fichiers ou plus. C'est le cas du module i3 qui comprend deux jeux de fichiers, FSi3i et FSi32 •
Le quatrième niveau est constitué par les fichiers eux-mêmes, Fin, Fil2, i21 , ?i22 , Fi3i, Fi32l et Fi322- Chaque jeu de fichiers peut comprendre un ou plusieurs fichiers .
Les troisième et quatrième niveaux constituent un niveau de visibilité interne ISTVi, non visible par l'utilisateur en utilisation normale. Cependant, les mises à jour concernent ce niveau.
Un domaine Dj est donc un ensemble de produits et de modules. Il comprend toujours, au minimum, un module et un jeu de fichiers spécifiques décrivant le domaine Dj . Ce jeu de fichiers spécifiques comprend, au moins, un fichier également spécifique contenant la liste, c'est-à-dire le nom et le numéro de version, de tous les autres jeux de fichiers du domaine Dj . Outre son rôle de conteneur, ce fichier particulier sert à assurer la cohérence du domaine Dj . En effet, tous les autres jeux de fichiers du domaine Dj sont déclarés dépendants du jeu de fichiers spécifiques. L'installation ou la mise à jour d'un jeu de fichiers quelconque, appartenant au domaine Dj, n'est possible que si la version du domaine le permet, du moins en ce qui concerne les produits contrôlés ou intégrés, c'est-à-dire d'un niveau d'insertion suffisamment élevé.
Enfin, dans un mode de réalisation particulier d'une architecture en domaine, illustré schématiquement par la figure 4, le système 1 peut comprendre un troisième domaine spécifique, 14, que l'on peut appeler domaine de service ou domaine "outils".
Ce domaine comprend, notamment, des produits logiciels ou des utilitaires, également spécifiques, permettant l'installation et/ou la mise à jour de tout ou partie des domaines, Di à On, et dans chaque domaine, de tout ou partie des produits, qu'ils soient d'origine interne, c'est-à-dire a priori entièrement intégrés aux domaines, ou externe, ces produits externes étant contrôlés ou non, selon le niveau d'insertion associé au domaine. Naturellement, les outils, ou "moteurs", d'installation et de mise à jour présents dans ce domaine sont en interaction avec les domaines, Di à Dn, ainsi qu'avec le domaine de base 11, et le domaine moniteur d' e.xploitation 13, et plus particulièrement avec leurs ensembles descripteurs 2. Les installations s'effectuent selon des règles enregistrées dans le domaine 14 et/ou les ensembles descripteurs 2.
Si on se reporte de nouveau à la figure 2, ce qui a été appelé descripteur 2 donne accès à, au moins, un enregistrement 20, contenant le nom et la version du domaine Dj, à un enregistrement 21, décrivant les attributs associés à ce domaine et à un enregistrement 22, de description du contenu du domaine et à un jeu de règles d'installation et de mise à jour du domaine et des produits le composant . Comme il a été décrit en regard de la figure 3, chaque domaine Dj comporte un jeu de fichiers spécifique contenant la liste des autres jeux de fichiers, c'est-à-dire au moins leurs noms et leurs numéros de version. On peut également compléter ces informations par des scripts et des règles d'installation et de mise à jour des produits externes au domaine.
Bien que les informations rappelées ci-dessus puissent être réparties à l'intérieur d'un domaine donné, celui-ci est "vu" de l'extérieur de façon identique, via l'ensemble descripteur 2 qui constitue une interface standard pour tous les domaines, même si le contenu de l'information accédée diffère d'un domaine à l'autre.
On va maintenant décrire le procédé selon l'invention par référence aux figures 5a à 5c.
En résumé de ce qui vient d'être rappelé en relation avec une architecture en domaines, on constate que chaque domaine Dj possède une structure qui permet de l'identifier et d'identifier ses composants logiciels : nom du domaine, numéro de version, fichier de référence descriptif des composants unitaires du domaine. C'est le rôle joué par le descriptif 2 (figure 2) , plus particulièrement des enregistrements 20 (nom et version du domaine) et 22 (description du contenu du domaine) , ainsi que du jeu de fichiers spécifique contenant la liste des autres fichiers (noms et numéros de version) . A titre d'exemple pratique, le numéro de version est associé à différents indices structurés qui peuvent se présenter sous la forme suivante : "v.r.m". "v" est un indice concernant la version livrée du domaine Dj . "r" est un indice dit de "release", c'est-à-dire de mise à disposition. Cet indice "r" indique des versions améliorées, mais sans changement fonctionnel majeur. L'indice "m" est relatif à la re-livraison de tout élément du domaine, fonctionnel ou non. Il est incrémenté à cette occasion, en général à partir de la valeur zéro (état initial) .
Toutes ces dispositions permettent de bien caractériser l'état initial d'un domaine particulier Dj, avec tous ses composants, ce qui constitue un avantage par rapport aux autre architectures.
Par contre, elles ne permettent pas de réaliser correctement le suivi des évolutions de ce domaine particulier Dj.
Aussi, selon une première caractéristique importante de l'invention, on ajoute à la structure existante un composant unitaire supplémentaire qui va permettre ce suivi, qui constitue un sous-ensemble du domaine.
Selon une deuxième caractéristique importante de 1 ' invention on utilise un indice supplémentaire représentatif des évolutions du domaine Dj, que l'on appellera ci-après indice "f" et qui est relatif aux lots de correction des domaines. Cet indice peut être avantageusement numérique, ce qui permet de le modifier simplement par incrémentation.
Sur la figure 5a, on a représenté un des domaines présents dans le système 1 de la figure 1 : le domaine Dj, d'indice arbitraire j. On suppose qu'il s'agit de l'état initial du domaine Dj, c'est-à-dire l'état dans lequel il a été livré pour sa première installation sur le système 1 (figure 1) . On suppose que le domaine Dj comprend N composants de diverses natures, référencés sur la figure 5a "composant #1" à "composant #N" . Ces composants sont associés à des indices de version qui peuvent être de structures diverses : date, numéros de version conformes à la structure précitée, à laquelle on a ajouté un quatrième indice (ce qui conduit à une structure similaire à "v.r.m.f") ou tout autre mode d'identification de version. À titre d'exemple, la version des composants "#1" et "#2" est repérée par une suite structurée du type "v.r.m.f" ("1.1.5.3" et "5.4.2.0", respectivement) , le composant "#3" par une date et les composants #4" et "#5" par de simples numéros ("32.104" et "12", respectivement). Le composant numéro "#N" par un mode non explicitement précisé (référencé "<ident>"). A priori, il n'y a pas de règles formelles pour identifier la version des composants. Toutes méthodes d'identification n'introduisant pas d'ambiguïté peut être utilisée.
L'ensemble des composants "composant #1" à
"composant #N" , repéré 4 sur la figure 5a, constitue un ensemble logiciel dont on veut suivre 1 ' évolution dans le temps, pour en garantir la cohérence par rapport à une référence donnée .
Dans le cas d'une architecture en domaines, qui constitue une architecture préférentielle, l'ensemble logiciel 4 peut être assimilé à la partie 3 (figure 2) d'un domaine Dj .
On associe (lien figuré par un trait plein lχ) à l'ensemble logiciel proprement dit 4, un premier composant ou sous-ensemble 5 identifiant cet ensemble logiciel, par exemple le domaine Dj . Ce composant est un enregistrement comprenant deux parties : une partie "nom" 50, et une partie "numéro ou identifiant de version de domaine" 51 (et de façon plus générale, d'ensemble logiciel).
A titre d'exemple, le nom 50 peut avoir la structure composée suivante "<nom_domaine> .saga_Id" , dans laquelle "<nom_domaine>" est un nom de domaine arbitraire et "saga_Id" un suffixe permettant d'identifier un objet de type domaine, et de façon plus générale l'appartenance à un type d'entité logicielle déterminée.
Le numéro de version 51 aura avantageusement une structure similaire à la structure "v.r.m.f" précitée. A pri ori , le quatrième indice élémentaire est égal à zéro. Dans l'exemple illustré, le numéro de version du domaine 51 est "3.2.1.0".
Un deuxième composant ou sous-ensemble 6 est associé à l'ensemble logiciel 4, il s'agit d'un composant entièrement spécifique à l'invention. Ce composant 6 est un enregistrement identifiant l'évolution de l'ensemble logiciel 4. La structure de ce composant est similaire à celle du composant 5. Elle comprend une partie "nom" 60 et une partie "numéro de version d'évolution" 61, cette dernière étant conforme à la structure "v.r.m.f" précitée. L'indice partiel principal, caractéristique de cette structure, est l'indice supplémentaire "f" indiquant le numéro du lot de correction. La partie nom 60 permet de lier l'enregistrement à un ensemble logiciel donné 4, notamment à un domaine dans l'application préférée. Elle a la structure suivante : "<nom_domaine> .<label>" , dans laquelle "<nom_domaine>" est le nom du domaine, et plus généralement le nom de l'ensemble logiciel, et "<label>" un suffixe qui permet d'identifier le composant supplémentaire, c'est-à- dire le type d'enregistrement 6.
A priori , à l'état initial, c'est-à-dire l'état représenté sur la figure 5a, l'indice élémentaire "f" (numéro du lot de correction) est égal à zéro et le "numéro de version d'évolution" 61 est identique au numéro de version de domaine 51, soit "3.2.1.0" dans l'exemple illustré .
On a représenté sous la référence 8, l'état courant de la machine, et plus particulièrement de la composition de chaque ensemble logiciel 4. Cet état courant comprend au moins des entrées identifiant les composants élémentaires : "composant #1" à "composant #N" , ainsi que leurs numéros de version. Dans le cas d'une architecture en domaines, qui constitue l'architecture préférentielle, si on se reporte de nouveau à la figure 4, l'état courant de la machine est géré, a priori, par le moniteur d'exploitation 13. Dans une architecture autre que l'architecture en domaine, cet état de la machine est géré par une entité similaire ou par le système d'exploitation.
On va maintenant illustrer le processus d'identification et de suivi des corrections apportées aux composants du domaine Dj, qui porte le nom arbitraire de "nom_domaine" , par référence plus particulière aux exemples illustrés par les figures 5b et 5c. Le numéro du lot de corrections (version courante) est repéré par l'indice f = 1 (cas de la première version de lot de correction : figure 5b) .
Dans un premier temps, on suppose que les composants numéros "#3" et "#5" sont modifiés, c'est-à-dire mis à jour.
Le composant "#3", dont l'identifiant de version est une date (anciennement "25/06/96" dans l'exemple décrit), a été mis à jour. La date de la nouvelle version est la suivante : "28/11/97".
Le composant "#5" dont l'identifiant de version est un simple numéro de version (anciennement "12") a été également mis à jour et son nouveau numéro de version est "15".
L'enregistrement 5 n'évolue pas, car le nombre et la répartition des composants de l'ensemble logiciel 4 n'ont pas été modifiés, seules les versions de tout ou partie des composants ont été changées (en l'occurrence les composants "#3" et "#5") . Par contre l'identifiant d'évolution, c'est-à-dire l'enregistrement identifiant les corrections apportées à l'ensemble logiciel 4, référencé désormais 6' (avec ses deux parties 60' et 61'), va être mis à jour et notamment l'indice "f" précité (numéro de lot de corrections) va être incrémenté d'une unité. Le numéro de version d'évolution 61' devient donc "3.2.1.1", dans l'exemple décrit.
Selon une caractéristique supplémentaire de l'invention, un lot de corrections donné (repéré par l'indice "f" précité) est accompagné d'un fichier 7', ou suite d'enregistrements, qui identifie les noms des composants du lot de corrections apporté et leur version.
En outre, de façon avantageuse, à chaque modification de l'enregistrement 6, correspond un fichier 7' différent, ce qui permet de conserver l'historique des corrections apportées aux composants de 1 ' ensemble logiciel 4, c'est-à-dire son évolution dans le temps depuis son état initial (figure 5a) . Ces fichiers seront référencés 7' (figure 5b), 7" (figure 5c), etc.
Un lien 12 (trait plein) symbolise la mise à jour du composant 6 (et notamment de la partie 61') et la création d'un fichier 7' associé au composant 6'.
Dans le cas du lot de corrections d'indice f = 1, illustré par la figure 5b, le fichier 7' comprend des entrées pour les composants #3 et #5, qui seuls ont été modifiés par rapport à l'état initial de l'ensemble logiciel 4. Les composants mis à jour, #3 et #5, voient leur identifiant de version mis en concordance avec le nouvel état atteint : une nouvelle date de version pour le composant "#3" et un nouveau numéro de version pour le composant "#5" .
Au nouvel enregistrement 6 ' , va correspondre aussi une mise à jour de l'état 8' de l'ensemble logiciel 4. La figure 5c illustre une nouvelle modification de tout ou partie des composants de l'ensemble logiciel 4 (lot de corrections f = 2) , en l'occurrence les composants "#1" et, de nouveau, le composant "#5". Le composant "#1" passe du numéro de version "1.1.5.3" au numéro de version "1.2.0.0" et le composant "#5" du numéro de version "15" au numéro de version "16".
Comme précédemment, l'enregistrement 5 reste inchangé et conserve le numéro de version d'ensemble logiciel "3.1.2.0" dans l'exemple décrit.
L'enregistrement identifiant l'évolution devient 6" (avec ses deux parties 60" et 61"), l'indice "f" étant de nouveau incrémenté d'une unité. Le numéro d'identifiant d'évolution 61" devient "3.2.1.2" dans l'exemple décrit.
De même, on créé un nouveau fichier 7" qui identifie les noms des composants du lot de corrections apporté (indice f = 2) et leurs versions. Dans le cas illustré par la figure 5c, les composants mis à jour étant "#1" et "#5", le fichier 7" comprend des entrées pour ces deux composants, qui seuls ont évolués par rapport à la modification précédente (figure 5b : indice f = 1) .
Comme précédemment, au nouvel enregistrement 6", va correspondre aussi une mise à jour de l'état 8" de l'ensemble logiciel 4.
En résumé, lors de l'installation d'un ensemble logiciel 4 (plus particulièrement, dans l'application préférée, lors de l'installation d'un domaine Dj) , le composant supplémentaire 6 conforme à 1 ' invention est implémenté en même temps que cet ensemble logiciel.
Ensuite, chaque ensemble cohérent de modifications
(lots de corrections f = x, avec x = 1, 2, etc.) est décrit dans un ensemble de fichiers 7', 7", etc., chacun étant attaché à une nouvelle version du composant spécifique à l'invention, c'est-à-dire les enregistrements 6', 6 " , etc. Les fichiers 7', 7", etc., comprennent des enregistrements avec les noms des composants du lot de corrections et leurs versions .
La première version des modifications est identifiée par un numéro d'évolution de version "v.r.m.l" (la version initiale étant "v.r.m.O") et les suivantes par incrémentation de "f" (f=2, 3, 4, etc.).
L'application sur site d'un ensemble cohérent de modifications (lot de corrections) sur un système 1
(figure 1) est toujours accompagnée d'une nouvelle version de l'enregistrement 6, et plus particulièrement de la partie 61 (l'indice "f" étant incrémenté d'une unité), ce qui constitue une signature électronique de la modification apportée .
Tous les ensembles de modifications sont disjoints les uns des autres : la version "f+1" d'un ensemble de corrections ne contient pas les corrections de la version précédente "f".
Chaque ensemble de corrections possède son propre ensemble de fichiers descriptifs, 7', 7", etc. Ainsi l'historique complet des différentes évolutions restent tracées sur le site client. En d'autres termes tous les fichiers intermédiaires restent disponibles et permettent de reconstituer l'évolution complète de l'ensemble logiciel.
•* Enfin, jusqu'à présent, on a considéré, au moins implicitement, que les fichiers successifs 7', 7", etc. ne contenaient que des informations sur les noms de composants et sur les versions successives de ceux-ci.
Dans une variante préférée de l'invention, ces fichiers sont complétés avantageusement par des fichiers en mode texte (non représentés) documentant chacune des modifications apportées aux composants. Les opérations de comparaison de l'état courant, 8 'ou 8", de l'ensemble logiciel 4 présent sur le système 1 (selon le niveau d'évolution atteint par l'ensemble logiciel 4 et déterminé par l'indice "f") par rapport au fichier de référence joint à chaque nouvel ensemble de corrections (fichier correspondant à l'indice "f+1") peuvent être simplifiées en faisant appel à des outils d'administration spécialisés externes ou internes au système 1. En particulier, ces outils peuvent faire partie avantageusement du domaine spécifique 14, illustré par la figure 4, ou domaine de service (dans la mesure où. ce domaine existe sur le système 1) . Dans une variante supplémentaire, les opérations peuvent être laissées sous le contrôle du domaine de base, ou système d'exploitation ("OS") 11 (figure 1), qui existe sur toute machine.
Le procédé selon 1 ' invention permet de suivre également les évolutions d'un nouveau domaine (ou de façon plus générale d'un nouvel ensemble logiciel) . En effet, le composant supplémentaire 6 étant lié à un domaine particulier, si on ajoute un domaine, par exemple un domaine D (avec p arbitraire) , ce composant 6 est implémenté en même temps que le nouveau domaine Dp. On considère qu'il s'agit d'un état initial et l'indice "f" prend la valeur zéro lors de la création du domaine Dp.
Lors des évolutions éventuelles ultérieures du domaine, le processus détaillé ci-dessus est réalisé et il est inutile de le redécrire.
De même la suppression d'un domaine quelconque (ou de façon plus générale d'un ensemble logiciel) , par exemple le domaine Dp précité, ne pose pas de problèmes de suivi non plus, toujours pour les mêmes raisons. Le composant supplémentaire 6 étant lié à ce domaine Dp, il disparaît avec ce domaine. Toutefois, les fichiers successifs 7', 7", etc., peuvent rester enregistrés dans le système 1, à titre d'historique. Dans les deux cas, c'est le moniteur d'exploitation, c'est-à-dire le domaine 13, pour l'architecture en domaines de la figure 1 qui identifie complètement l'ensemble du système 1 et ses composants de base, c'est-à-dire les domaines Di à On .
Enfin, lorsque la composition de l'un des domaines (ou de façon plus générale d'un ensemble logiciel) , par exemple le domaine Dj, est modifiée, non pas par simple correction ou changement de version d'un composant, mais par ajout ou suppression d'un ou plusieurs composants, il est nécessaire de faire évoluer la version du domaine : numéro de version du domaine 51, de l'enregistrement 5.
A la lecture de ce qui précède, on constate aisément que l'invention atteint bien les buts qu'elle s'est fixés.
II doit être clair cependant que l'invention n'est pas limitée aux seuls exemples de réalisations explicitement décrits, notamment en relation avec les figures 5a à 5c.
En particulier, la numérotation des versions des composants, des domaines et des évolutions peut être réalisée de diverses façons. Seul l'indice élémentaire, qui a été appelé de façon arbitraire "f" concerne directement le procédé de l'invention, car identifiant le niveau d'évolution des corrections apportées aux composants de l'ensemble logiciel. Il peut cependant être remplacé par un moyen similaire permettant de refléter des états successifs, que ce moyen soit purement logiciel (octet, etc.) ou matériel (compteur incrémenté). De même, s'il est usuel de forcer 1 ' indice précité ou son équivalent à la valeur zéro pour identifier un état initial, cette convention est purement arbitraire et d'autres conventions peuvent être adoptées sans sortir du cadre de l'invention. On pourrait notamment utiliser les lettres de l'alphabet, au lieu d'un indice numérique ou tout autre convention établissant une relation biunivoque entre l'indice utilisé et le lot de correction. Il doit être clair aussi que, bien que particulièrement adaptée à une architecture de système en domaines telle qu'elle a été définie dans la présente description, on ne saurait cantonner l'invention à ce seul type d'architecture. Elle s'applique au suivi de tout ensemble logiciel multicomposants .

Claims

R E V E N D I C A T I O N S
1. Procédé d'identification et de suivi des évolutions d'un ensemble de composants logiciels déterminé (4) dans un système de traitement de l'information (1), chaque composant (#1 à #N) étant repéré par un nom et un identifiant de version, et chaque ensemble de composants logiciels (4) étant lié di) à un premier sous-ensemble (5) comprenant un identifiant (50, 51) dudit ensemble logiciel et de sa version, caractérisé en ce que les modifications apportées à tout ou partie desdits composants (#1 à #N) d'un ensemble de composants logiciels déterminé (4) sont repérées par un indice dit de lot de corrections, en ce que l'ensemble de composants logiciels déterminé (4) est associé à un second sous-ensemble (6, 6', 6") comprenant un identifiant (60, 60', 60") dudit ensemble de composants logiciel déterminé (4) et dudit lot de corrections et d'un identifiant de version d'évolution (61, 61', 61"), cet identifiant de version d'évolution (61, 61', 61") comprenant au moins ledit indice de lot de correction, et en ce que ledit second sous-ensemble (6', 6") est lié (I2) à au moins une première suite d'enregistrements (7', 7") décrivant les noms des composants dudit lot de corrections (#3-#5, #l-#5) et leurs versions.
2. Procédé selon la revendication 1, caractérisé en ce que, lors de l'implantation d'un nouveau ensemble de composants logiciels (4) sur ledit système de traitement de l'information (1), ledit second sous-ensemble associé (6) est implanté en même temps que celui-ci, et en ce que, ledit indice de lot de corrections étant un indice numérique, l'état initial dudit ensemble de composants logiciels déterminé (4) est repéré par la mise à la valeur zéro de cet indice.
3. Procédé selon la revendication 2, caractérisé en ce que ledit indice de lot de corrections est incrémenté d'une unité lors de la mise en place d'un nouveau lot de corrections modifiant tout ou partie desdits composants logiciels (#1 à #N) .
4. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que, pour chaque série de modifications de tout ou partie desdits composants logiciels (#1 à #N) correspondant à un nouveau lot de corrections, ledit identifiant de version d'évolution (61', 61") de ce dernier est modifié.
5. Procédé selon la revendication 4, caractérisé en ce que, pour chaque série de modifications de tout ou partie desdits composants (#1 à #N) correspondant à un nouveau lot de corrections, il est créé une nouvelle première suite d'enregistrements (7', 7"), associée audit second sous-ensemble modifié (6', 6") et identifiant lesdits composants logiciels modifiés et leurs nouvelles versions, cette nouvelle première suite d'enregistrements (7', 7") étant disjointe des versions précédentes.
6. Procédé selon la revendication 5, caractérisé en ce que toutes lesdites suites d'enregistrements créées (7', 7") restent stockées sur ledit système de traitement d'informations (1), de manière à constituer un historique des lots de corrections successivement appliqués audit ensemble de composants logiciels déterminé (4) .
7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ladite première suite d'enregistrements (7', 7") est associée à une seconde suite d'enregistrements comprenant des données informationnelles sur lesdites corrections appliquées par lesdits lots de corrections.
8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit identifiant (60, 60', 60") de l'ensemble de composants logiciels déterminé (4) et du lot de corrections dudit second sous- ensemble (6, 6', 6") est structuré de la façon suivante : <nom> . <label>, structure dans laquelle <nom> identifie le nom dudit ensemble de composants logiciels (4) et <label> un suffixe indiquant l'appartenance dudit second sous- ensemble (6') à un type d'entité logicielle déterminée.
9. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que ledit numéro de version d'évolution comprend un numéro de version dudit ensemble de composants logiciels déterminé (4) complété par ledit indice de lot de corrections.
10. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits ensembles de composants logiciels (4) sont constitués d'entités dites domaines (Dj) comprenant chacune au moins un desdits composants logiciels, en ce que chaque domaine (11-14) contient un sous-ensemble dit descripteur (2) donnant accès à des informations spécifiques déterminées (20-22) , lesdites informations comprenant au moins un identifiant (20) du domaine et des données (22) décrivant lesdits composants, l'installation et/ou la mise à jour desdits domaines (11-14) étant réalisées à partir de règles prédéterminées et desdites informations spécifiques déterminées (20-22) , et en ce que lesdits seconds sous- ensembles (6', 6") identifient lesdits domaines (Dj) auxquels ils sont liés et la version du lot de corrections courante appliquée à ces domaines (Dj) .
11. Procédé selon la revendication 10, caractérisé en ce que ledit identifiant (20) comprend au moins des informations de nom et de version de domaine (Dj) .
PCT/FR1998/002887 1997-12-30 1998-12-28 Procede d'identification et de suivi des evolutions d'un ensemble de composants logiciels WO1999035566A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
EP98963637A EP0961969A1 (fr) 1997-12-30 1998-12-28 Procede d'identification et de suivi des evolutions d'un ensemble de composants logiciels

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR9716700A FR2773242A1 (fr) 1997-12-30 1997-12-30 Procede d'identification et de suivi des evolutions d'un ensemble de composants logiciels
FR97/16700 1997-12-30

Publications (1)

Publication Number Publication Date
WO1999035566A1 true WO1999035566A1 (fr) 1999-07-15

Family

ID=9515296

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR1998/002887 WO1999035566A1 (fr) 1997-12-30 1998-12-28 Procede d'identification et de suivi des evolutions d'un ensemble de composants logiciels

Country Status (3)

Country Link
EP (1) EP0961969A1 (fr)
FR (1) FR2773242A1 (fr)
WO (1) WO1999035566A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100388486B1 (ko) * 2000-12-14 2003-06-25 한국전자통신연구원 객체 관계와 객체 이용 정보를 이용한 소프트웨어컴포넌트 식별 장치 및 그 방법
CN1322420C (zh) * 2004-01-18 2007-06-20 北京大学 构件化软件系统在线增加新功能的方法
WO2007068091A1 (fr) * 2005-12-12 2007-06-21 Audiokinetic Inc. Procede et systeme de creation numerique multiversion

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2846766B1 (fr) * 2002-10-31 2005-01-28 Jdv Procede d'identification et systeme de fichiers specialise pour la gestion de configuration
US11544233B2 (en) * 2020-06-24 2023-01-03 Citrix Systems, Inc. File source tracking

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0528617A2 (fr) * 1991-08-19 1993-02-24 Sun Microsystems, Inc. Procédé et dispositif pour le contrôle de changements dans plusieurs environnements de développement
US5649200A (en) * 1993-01-08 1997-07-15 Atria Software, Inc. Dynamic rule-based version control system

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0528617A2 (fr) * 1991-08-19 1993-02-24 Sun Microsystems, Inc. Procédé et dispositif pour le contrôle de changements dans plusieurs environnements de développement
US5649200A (en) * 1993-01-08 1997-07-15 Atria Software, Inc. Dynamic rule-based version control system

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100388486B1 (ko) * 2000-12-14 2003-06-25 한국전자통신연구원 객체 관계와 객체 이용 정보를 이용한 소프트웨어컴포넌트 식별 장치 및 그 방법
CN1322420C (zh) * 2004-01-18 2007-06-20 北京大学 构件化软件系统在线增加新功能的方法
WO2007068091A1 (fr) * 2005-12-12 2007-06-21 Audiokinetic Inc. Procede et systeme de creation numerique multiversion

Also Published As

Publication number Publication date
EP0961969A1 (fr) 1999-12-08
FR2773242A1 (fr) 1999-07-02

Similar Documents

Publication Publication Date Title
EP0889399B1 (fr) Architecture de système de traitement de l&#39;information
EP0793171B1 (fr) Système de configuration de logiciels préconfigurés sur des systèmes ouverts en réseau dans un environnement distribué et procédé mis en oeuvre par un tel système
US7664834B2 (en) Distributed operating system management
US8365164B1 (en) Portable software applications
FR2722015A1 (fr) Systeme de traitement d&#39;informations
US20030009752A1 (en) Automated content and software distribution system
US20090144718A1 (en) Systems and methods for updating software appliances
US20100023520A1 (en) Encapsulated file management systems
JP2003177947A (ja) ファイル空間管理の方法とシステム
FR2957164A1 (fr) Procedes et dispositifs de validation de configuration d&#39;un systeme multielements complexe
FR2877458A1 (fr) Systeme et procede de communication de reseau d&#39;image systeme de traitement de l&#39;information
WO2003044668A9 (fr) Systeme et procede permettant d&#39;ameliorer le support aux technologies de l&#39;information par la collecte, l&#39;evaluation et l&#39;enregistrement d&#39;informations relatives aux configurations, relatives aux evenements et de type metrique
EP0961969A1 (fr) Procede d&#39;identification et de suivi des evolutions d&#39;un ensemble de composants logiciels
FR2823932A1 (fr) Systeme et procede pour la distribution dynamique de donnees et/ou de services
WO2005008509A2 (fr) Procede de gestion des composants logiciels integres dans un systeme embarque
EP3191961A1 (fr) Mecanisme haute performance pour generation d&#39;informations de journalisation d&#39;un processus informatique
EP0969625A1 (fr) Agent de communication entre un administrateur et au moins une ressource d&#39;un système informatique
FR2765363A1 (fr) Procede et systeme de controle de l&#39;utilisation d&#39;un logiciel
FR2913122A1 (fr) Systeme d&#39;information embarque a restauration automatique
EP1341087B1 (fr) Procédé et système de gestion d&#39;un journal personnel d&#39;évènements
EP2946289A1 (fr) Optimisation de modules informatiques pour le deploiement d&#39;un service informatique
EP1054332A1 (fr) Système et procédé de gestion d&#39;attributs dans un environnement orienté objet
FR2908909A1 (fr) Procede de gestion d&#39;une unite de calcul
EP1902363A1 (fr) Procede pour la prise en compte automatique et le stockage persistant de parametres de personnalisation a priori volatils
WO2010052441A1 (fr) Procede et systeme de synchronisation d&#39;un ensemble de modules logiciels d&#39;un systeme informatique distribue en grappe de serveurs

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE

WWE Wipo information: entry into national phase

Ref document number: 1998963637

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 09380245

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWP Wipo information: published in national office

Ref document number: 1998963637

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 1998963637

Country of ref document: EP