EP1599795A2 - Procede de developpement automatise avec mise a jour - Google Patents

Procede de developpement automatise avec mise a jour

Info

Publication number
EP1599795A2
EP1599795A2 EP04712052A EP04712052A EP1599795A2 EP 1599795 A2 EP1599795 A2 EP 1599795A2 EP 04712052 A EP04712052 A EP 04712052A EP 04712052 A EP04712052 A EP 04712052A EP 1599795 A2 EP1599795 A2 EP 1599795A2
Authority
EP
European Patent Office
Prior art keywords
level
design
class
name
analysis
Prior art date
Legal status (The legal status 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 status listed.)
Withdrawn
Application number
EP04712052A
Other languages
German (de)
English (en)
Inventor
Dominique Sueur
Madeleine Faugere
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales SA
Original Assignee
Thales SA
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 Thales SA filed Critical Thales SA
Publication of EP1599795A2 publication Critical patent/EP1599795A2/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/10—Requirements analysis; Specification techniques

Definitions

  • the present invention relates to an automated development method with updating.
  • a design level can, for example, be expressed as UML models
  • Fig 1 First development.
  • the first level of design is called "Problem specification”. It is at this level that the customer defines his need: each aircraft is characterized by a name (A3XX), a number of passengers (600) and a number of engines (4). 2.
  • the level “Analysis of the problem” is carried out in UML.
  • This analysis step is still very much linked to the field of the trade concerned. At the end of this stage, we can still see the concepts of "airplane”, “passenger”, and "engine” (this information is noted in quotes. These are the significant objects of the level of design considered).
  • This analysis step also reveals new information such as the reservation, the name and the nationality of the passengers. This information refines concepts of the previous design level; they cannot be deducted automatically: these are the designer's choice of design.
  • reaction iii. a stereotypical “passenger” class with the name “person”.
  • b. create a relationship (UML composition link) named “motorization” between the stereotypical class “airplane” and the stereotypical class “engine” with as cardinalities (number / digit) a class side stereotypical “airplane”, value of number of engines class side stereotypical “engine”.
  • vs. create an association link named "passenger” between the stereotypical class "airplane” and the stereotypical class "passenger” with cardinalities as an airplane side, value of number of passengers on the stereotypical class side "passenger”.
  • R 3 For any class stereotyped “airplane” at the “problem analysis” level, the algorithm consists of: a. create a class without stereotype at the level “design of a solution” having the same name as the name of the stereotyped class “airplane” at the level of design “analysis of the problem”; b. create an inheritance relationship from the newly created class to the stereotypical "Active”class; A: For any stereotypical "passenger” class at the "problem analysis” level, the algorithm consists of: a. create a class without stereotype at the level “design of a solution” having the same name as the name of the stereotyped class “passenger” at the level of design “analysis of the problem”; b. create an inheritance relationship from the newly created class to the stereotypical "Active”class;
  • R 5 For any stereotyped class “engine” at the “problem analysis” level, the algorithm consists of: a. create a class without stereotype at the level “design of a solution” having the same name as the name of the stereotyped class “engine” of the level of design “analysis of the problem”; b. create an inheritance relationship from the newly created class to the stereotypical "Active"class;
  • the algorithm For any non-stereotyped class at the “problem analysis” level, the algorithm consists of: a. create a class without stereotype at the level of “design of a solution” having the same name as the name of the class of the level of design “analysis of the problem”; A: For any association linking two classes A and B at the “problem analysis” level, the algorithm consists of: a. create an association at the "design of a solution” level linking the classes from A and B by the transformation algorithm. The cardinalities (the numbers) and the role (the name) are identical to those of the design level "analysis of the problem”; R 8 : For any operation of a class A at the “problem analysis” level, the algorithm consists of: a. create an operation at the “design of a solution” level having the same name as the name of the operation at the “analysis of the problem” design level; b. associate this operation with the class from A by the transformation algorithm.
  • R g For any attribute of a class A at the “problem analysis” level, the algorithm consists of: a. create an attribute at the “design of a solution” level having the same name as the name of the operation at the “analysis of the problem” design level; vs. associate this attribute to the class from A by the transformation algorithm. Designing a complex system, as outlined briefly above, involves several design steps and may require many iterations. At each iteration, the designer questions his choices. He makes modifications to improve his models. However, the transformation rules mechanism does not take this aspect into account.
  • the modifications are taken into account from the construction point of view for the reconstruction of a level N + 1 from the level N, but there is no integration of the modifications with the information already existing at a level N + 1 previously created and completed manually. All information that had been entered manually is lost when the rules are re-applied.
  • the problem is to go automatically or semi-automatically from a design level N to a level N + 1 (or more generally from one model to another) with the following constraints: • keep the information added at the level below - N + 1 overlay when re-applying the rules; • keep and explain all the information used during the application of the rules so as to be able to reproduce the process (this information will be called rule parameters). Saving them allows the rules to be re-applied without further interaction with the designer.
  • the present invention relates to an automated development process coupling traceability and transformation.
  • the method according to the invention is an automated development method with transformation rules making it possible to go from one model to another, with updating, and it is characterized by the fact that each model element is associated automatically produces at least one traceability link with all of the elements from which it originates according to the transformation rule.
  • the elements used are UML elements.
  • a UML "dependency" is used to establish the traceability link, the "dependency" being as defined at OMG in the definition of the UML language.
  • FIG. 1, cited above, is a block diagram of a first development of an air traffic simulation program
  • FIG. 2 is a block diagram resulting from that of FIG. 1, as obtained after a non-conservative transformation, according to the prior art
  • FIG. 3 is a block diagram resulting from that of FIG. 1, as obtained after a conservative transformation, according to the method of the invention,
  • FIG. 4 is a block diagram illustrating the automatic construction of the level of analysis according to the method of the invention (the dotted lines represent the traceability link which has been created),
  • FIG. 5 is a block diagram illustrating the manual enrichment of the level of analysis by the designer (information in italics and in thin lines).
  • FIG. 6 is a block diagram illustrating the second iteration of the algorithm for implementing the method of the invention.
  • the designer modified the specification of the problem by changing the name of the aircraft and then re-applied the rules to update his model.
  • the invention proposes to associate with the transformation rules elements of traceability.
  • the application of the transformation rules alone ensures only an ephemeral traceability link between elements of a source design level and the corresponding elements of the target design level.
  • the invention proposes to couple a traceability mechanism with a transformation mechanism. For this, we add elements to the rules which:
  • the transformation-conservative mechanism of the invention makes it possible to maintain consistency in design levels by applying rules coupled with elements of traceability. With this mechanism, it is possible to rename PA3XX to A380 and to automatically pass on this modification to all of the underlying levels without losing the information added manually (Cf. Fig 3: Conservative transformation).
  • the conservative transformation mechanism supports incremental and iterative development. It also supports endomorphic transformations (within a single design level). This mechanism can also be used to propagate marks used to delete elements via rules similar to those in the example.
  • the invention proposes a traceability mechanism coupled with the transformation rules, making it possible to make the link between the elements produced by the transformation and the elements from which they originate, as well as the information called parameters of the transformation rule.
  • this link traceability link. It is a logical link, which links n source elements, to m target elements. Definitions:
  • Link S, C, R the traceability element between S, and C which can be associated with specific parameters (PARAM s, R) to the application of R on S.
  • PARAM s, R specific parameters
  • the set C is obtained by following the Link s ⁇ from S. For any element of C, we assign the values calculated from S, R and possibly PARAMs ⁇ .
  • the first phase is the creation of the analysis model by a first iteration of the algorithm (Cf: Figure 4)
  • A3XX a stereotyped “project” directory bearing the name of the aircraft in the description (ie A3XX) comprising: i. a stereotypical “airplane” class called A3XX, ii. a stereotypical “engine” class with the name “reaction”, iii. a stereotypical “passenger” class with the name “person”.
  • b. create a composition link called “motorization” between the stereotyped class “airplane” and the stereotyped class “engine” with a cardinality 1 side class stereotyped “plane”, and 4 side class stereotyped “engine”.
  • vs. create an association link named "passenger” between the stereotypical class "plane” and the stereotypical class "passenger” with a cardinality 1 class side stereotyped "plane”, 600 class side stereotyped "passenger”.

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)
  • Feedback Control In General (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Devices For Executing Special Programs (AREA)

Abstract

Le procédé conforme à l'invention est un procédé de développement automatisé avec mise à jour, à plusieurs étapes de conception, avec règles de transformation permettant de passer d'une étape à la suivante, et il est caractérisé par le fait que l'on associe à chaque élément produit automatiquement au cours de la conception au moins un lien de traçabilité avec l'élément à partir duquel il est issu selon la règle de transformation.

Description

PROCEDE DE DEVELOPPEMENT AUTOMATISE AVEC MISE A JOUR
La présente invention se rapporte à un procédé de développement automatisé avec mise à jour.
Le développement d'un système complexe nécessite différentes étapes de résolution de problèmes et de conception incrémentale. L'objectif est de construire la spécification d'une solution répondant à la spécification d'un problème. Dans le domaine logiciel, la spécification d'un besoin client donne lieu à la réalisation d'un document d'analyse, puis d'un document de conception et se termine par la réalisation du programme attendu. L'analyse, la conception et la réalisation permettent de construire de manière incrémentale une solution en expliquant la démarche de construction. Ces différentes étapes facilitent la maintenance du programme qui résulte des différentes étapes de conception et permettent de faire évoluer le logiciel ainsi produit en fonction des besoins du client.
Quel que soit le domaine d'application, il est possible de formaliser, avec les langages appropriés, les étapes de construction ainsi que leurs résultats, qui seront appelées par la suite niveaux de conception. Un niveau de conception peut, par exemple, être exprimé sous forme de modèles UML
(Unified Modeling Language).
Il est possible de générer partiellement un niveau de conception en fonction du niveau de conception qui le précède à partir de règles de transformation. De nouvelles informations doivent cependant être introduites manuellement pour enrichir le modèle nouvellement créé et raffiner les concepts de manière à converger vers le niveau de détail attendu pour la réalisation de la solution.
L'approche incrémentale est illustrée à l'aide d'un exemple très simplifié pris dans le domaine de la simulation du trafic aérien, et schématisé en Fig 1 : Premier développement. Cette figure comporte trois niveaux de conception : 1. Le premier niveau de conception est appelé « Spécification du problème ». C'est à ce niveau que le client définit son besoin : chaque avion est caractérisé par un nom (A3XX), un nombre de passagers (600) et un nombre de moteurs (4). 2. Le niveau « Analyse du problème » est réalisé en UML. Cette étape d'analyse est encore très liée au domaine du métier concerné. A l'issue de cette étape, on voit encore apparaître les notions d'« avion », de « passager », et de « moteur » (ces informations sont notées entre guillemets. Ce sont les objets signifiants du niveau de conception considéré ). Cette étape d'analyse fait aussi apparaître de nouvelles informations telles que la réservation, le nom et la nationalité des passagers... Ces informations raffinent des concepts du niveau de conception précédent ; elles ne peuvent pas être déduites automatiquement : ce sont les choix de réalisation du concepteur.
3. Le niveau « conception d'une solution » est beaucoup plus « technique ». Le langage utilisé n'est plus lié au domaine aérien. On ne s'intéresse plus aux notions d'avion ou de passagers. On met l'accent sur la notion d'acteur (objet informatique déclenchant des traitements) qu'il faut simuler. C'est à ce niveau que sont définies précisément les actions à exécuter dans un langage proche de celui directement compréhensible par l'ordinateur (par exemple le C++).
Dans la Fig 1 : Premier développement, tous les éléments en trait fin ou en caractères italiques explicitent les informations ajoutées manuellement. Toutes les informations représentés en caractère ou trait gras sont obtenus automatiquement par application des règles de transformation
R-i à Rg suivantes :
• Création du niveau de conception « Analyse du problème » : Ri : Pour tout descriptif d'avion comportant un nom, un nombre de passagers et un nombre de moteurs, l'algorithme consiste à : a. créer un répertoire stéréotypé « projet » au nom de l'avion (nom) comprenant : i. une classe stéréotypée « avion » nommée « nom » (nom faisant référence au nom d'avion), ii. une classe stéréotypée « moteur » ayant pour nom
« réaction », iii. une classe stéréotypée « passager » ayant pour nom «personne ». b. créer une relation (lien de composition UML) nommée « motorisation » entre la classe stéréotypée « avion » et la classe stéréotypée « moteur » avec comme cardinalités (nombre/chiffre) un côté classe stéréotypée « avion », valeur de nombre de moteurs côté classe stéréotypée « moteur ». c. créer un lien d'association nommé « passager » entre la classe stéréotypée « avion » et la classe stéréotypée « passager » avec comme cardinalités un côté avion, valeur de nombre de passagers côté classe stéréotypée « passager ». • Création du niveau de conception « Conception d'une solution » : R2 : Pour tout répertoire stéréotypé « projet » au niveau « analyse du problème » l'algorithme consiste à: a. créer un répertoire stéréotypé « Design » au niveau « conception d'une solution » ayant le même nom que le nom du répertoire stéréotypé « projet » du niveau de conception « analyse du problème » ; b. créer une classe « Acteur » stéréotypée « Active » ;
R3 : Pour toute classe stéréotypé « avion » au niveau « analyse du problème » l'algorithme consiste à : a. créer une classe sans stéréotype au niveau « conception d'une solution » ayant le même nom que le nom de la classe stéréotypé « avion » du niveau de conception « analyse du problème » ; b. créer une relation d'héritage allant de la classe nouvellement créée à la classe stéréotypée « Active » ; R : Pour toute classe stéréotypé « passager » au niveau « analyse du problème » l'algorithme consiste à : a. créer une classe sans stéréotype au niveau « conception d'une solution » ayant le même nom que le nom de la classe stéréotypé « passager » du niveau de conception « analyse du problème » ; b. créer une relation d'héritage allant de la classe nouvellement créée à la classe stéréotypé « Active » ;
R5 : Pour toute classe stéréotypé « moteur » au niveau « analyse du problème » l'algorithme consiste à: a. créer une classe sans stéréotype au niveau « conception d'une solution » ayant le même nom que le nom de la classe stéréotypé « moteur » du niveau de conception « analyse du problème » ; b. créer une relation d'héritage allant de la classe nouvellement créée vers la classe stéréotypé « Active » ;
Re : Pour toute classe non stéréotypé au niveau « analyse du problème » l'algorithme consiste à : a. créer une classe sans stéréotype au niveau « conception d'une solution » ayant le même nom que le nom de la classe du niveau de conception « analyse du problème » ; R : Pour toute association reliant deux classes A et B au niveau « analyse du problème » l'algorithme consiste à : a. créer une association au niveau « conception d'une solution » reliant les classes issues de A et B par l'algorithme de transformation. Les cardinalités (les chiffres) et le rôle (le nom) sont identiques à ceux du niveau de conception « analyse du problème » ; R8 : Pour toute opération d'une classe A du niveau « analyse du problème » l'algorithme consiste à : a. créer une opération au niveau « conception d'une solution » ayant le même nom que le nom de l'opération du niveau de conception « analyse du problème » ; b. associer cette opération à la classe issue de A par l'algorithme de transformation.
Rg : Pour tout attribut d'une classe A du niveau « analyse du problème » l'algorithme consiste à : a. créer un attribut au niveau « conception d'une solution » ayant le même nom que le nom de l'opération du niveau de conception « analyse du problème » ; c. associer cet attribut à la classe issue de A par l'algorithme de transformation. La conception d'un système complexe, telle qu'exposée succinctement ci-dessus, implique plusieurs étapes de conception et peut nécessiter de nombreuses itérations. A chaque itération, le concepteur remet en cause ses choix. Il effectue des modifications pour améliorer ses modèles. Or, le mécanisme de règles de transformation ne prend pas en compte cet aspect. Lors de la ré-application des règles, les modifications sont prises en compte du point de vue de la construction pour la reconstruction d'un niveau N+1 à partir du niveau N, mais il n'y a pas d'intégration des modifications avec les informations déjà existantes à un niveau N+1 précédemment créé et complété manuellement. Toutes les informations qui avaient été introduites manuellement sont perdues lors de la ré-application des règles.
Le problème est de passer de manière automatique ou semi- automatique d'un niveau de conception N à un niveau N+1 (ou plus généralement d'un modèle à un autre) avec les contraintes suivantes : • conserver les informations ajoutées au niveau sous-jacent N+1 lors de la ré-application des règles; • conserver et expliciter toutes les informations utilisées lors de l'application des règles de façon à pouvoir reproduire le processus (ces information seront appelées paramètres de la règle). Leur sauvegarde permet la ré-application des règles sans nouvelle interaction avec le concepteur.
• Cette conservation d'informations n'est pas réalisée avec les procédés connus. Elle est essentielle pour maintenir et faire évoluer les niveaux de conception, et ne peut se faire que par le couplage de la transformation avec la traçabilité, ce couplage faisant l'objet de la présente invention, comme détaillé ci-dessous.
A titre d'exemple, pour illustrer l'inconvénient principal des procédés connus, on se propose de changer le nom de l'avion A3XX en A380 au niveau « Descriptif spécification du problème », le nom de A380 ayant été finalement choisi, puis de ré-appliquer les règles précédemment citées. En appliquant le seul mécanisme connu de règles de transformation, on obtient les modèles présentés Fig 2 : Transformation non conservative. Toutes les occurrences du nom A3XX ont été correctement remplacées par A380 mais toutes les informations ajoutées manuellement (informations en italique et en trait fin sur les différentes figures), lors de la première itération, au niveau « Analyse du problème » et « Conception d'une solution » sont perdues. Cette solution est inacceptable : pour ne pas perdre tout son travail, le concepteur doit renoncer à l'utilisation des règles de transformation et répercuter manuellement la modification (le nom de l'avion) à tous les niveaux de conception sous-jacents, là où c'est nécessaire et avec tous les risques d'incohérences que cela représente. Pour effectuer ce travail, le concepteur peut, à l'aide des outils qui existent, établir des éléments de traçabilité pour relier toutes les occurrences du nom A3XX. Ces liens lui permettront de localiser toutes les modifications à effectuer lors du changement de nom, mais ces modifications resteront à sa charge. Les mécanismes de transformation et de traçabilité sont gérés de façon indépendante.
La présente invention a pour objet un procédé de développement automatisé couplant la traçabilité et la transformation.
Le procédé conforme à l'invention est un procédé de développement automatisé avec règles de transformation permettant de passer d'un modèle à un autre, avec mise à jour, et il est caractérisé par le fait que l'on associe à chaque élément de modèle produit automatiquement au moins un lien de traçabilité avec l'ensemble des éléments à partir duquel il est issu selon la règle de transformation.
Selon une autre caractéristique de l'invention, les éléments manipulés sont des éléments UML. De façon avantageuse, on utilise une « dependency » UML pour établir le lien de traçabilité, la « dependency » étant telle que définie à l'OMG dans la définition du langage UML.
Selon encore une autre caractéristique de l 'invention, le procédé de l'invention est utilisé pour mettre en oeuvre des « Design patterns ». La présente invention sera mieux comprise à la lecture de la description détaillée d'un mode de réalisation, pris à titre d'exemple non limitatif et illustré par le dessin annexé, sur lequel :
- la figure 1 , citée ci-dessus, est un bloc-diagramme d'un premier développement de programme de simulation de trafic aérien,
- la figure 2, également citée ci-dessus, est un bloc-diagramme résultant de celui de la figure 1 , tel qu'obtenu après une transformation non conservative, selon l'art antérieur,
- la figure 3 est un bloc-diagramme résultant de celui de la figure 1 , tel qu'obtenu après une transformation conservative, selon le procédé de l'invention,
- la figure 4 est un bloc-diagramme illustrant la construction automatique du niveau d'analyse selon le procédé de l'invention (les lignes en pointillées représentent le lien de traçabilité qui a été crée),
- la figure 5 est un bloc-diagramme illustrant l'enrichissement manuel du niveau d'analyse par le concepteur (informations en italique et en trait fin).
- la figure 6 est un bloc-diagramme illustrant la deuxième itération de l'algorithme de mise en œuvre du procédé de l'invention. Le concepteur à modifié la spécification du problème en changeant le nom de l'avion puis a ré-appliqué les règles pour mettre à jour son modèle.
L'invention propose d'associer aux règles de transformation des éléments de traçabilité. L'application des seules règles de transformation n'assure qu'un lien de traçabilité éphémère entre des éléments d'un niveau de conception source et les éléments correspondants du niveau de conception cible. Cette liaison
(éléments sources, éléments cibles, et paramètres de la règle) n'existe que pendant l'application de la règle.
L'invention propose de coupler un mécanisme de traçabilité avec un mécanisme de transformation. Pour cela, on ajoute aux règles des éléments qui :
• explicitent la traçabilité complète entre éléments d'un niveau de conception source vers les différents éléments d'un niveau de conception cible,
• explicitent les paramètres de la règle (informations fournies par le concepteur nécessaire à l'application des règles),
• permettent la mise à jour d'un niveau de conception cible à partir d'un niveau de conception source sans impact sur les éléments non issus de l'application d'une règle lors d'une transformation antérieure. Le mécanisme de transformation- conservative de l'invention permet de maintenir en cohérence les niveaux de conception par application de règles couplées à des éléments de traçabilité. Avec ce mécanisme, il est possible de renommer PA3XX en A380 et de répercuter automatiquement cette modification à tous les niveaux sous-jacents sans perdre les informations ajoutées manuellement (Cf. Fig 3 : Transformation conservative). Le mécanisme de transformation conservative supporte le développement incrémental et itératif. Il supporte également les transformations endomorphes (au sein d'un unique niveau de conception). Ce mécanisme peut également servir à propager des marques servant à supprimer des éléments via des règles similaires à celles de l'exemple.
On va maintenant décrire de façon détaillée un mode de mise en oeuvre du procédé de l'invention. L'invention propose un mécanisme de traçabilité couplé aux règles de transformation, permettant de rendre pérenne le lien entre les éléments produits par la transformation et les éléments à partir desquels ils sont issus, ainsi que les informations appelées paramètres de la règle de transformation. On appelle ce lien, lien de traçabilité. C'est un lien logique, qui relie n éléments source, à m éléments cible. Définitions :
Soient
• R : une règle de transformation
• S : un ensemble d'élément(s) du modèle source (niveau N) • C: un ensemble d'éléments du modèle cible (N+1) , issu(s) de S, par application de la règle R,
• PARAMs, R : paramètre de la règle R appliquée a S. L'obtention de ces paramètres peut nécessiter un dialogue avec le concepteur.
• Lien S,C,R : l'élément de traçabilité entre S, et C qui peut être associé à des paramètres spécifiques (PARAM s, R ) à l'application de R sur S. L'algorithme de mise en oeuvre du procédé de l'invention comprend les trois parties suivantes:
Algorithme de transformation conservative :
Pour tout ensemble S sur lequel s'applique la règle R Si Lien S,C,R existe alors
Mise à jour de C et du Liens Γ. R Sinon
Création de C. du Lien s Γ. R et de PARAMs,
Mise à jour des C, et du Liens r. R
L'ensemble C est obtenu en suivant le Lien s^ issu de S. Pour tout élément de C, on affecte les valeurs calculées à partir de S, de R et éventuellement de PARAMs^.
Création de C. du lien S,Γ., et de PARAMS_R:
Création puis affectation (i.e fixation des valeurs) des éléments C par application de
R ainsi que création du lien s.c.Rβt des paramètres PARAMs, R (éventuellement vide).
On va maintenant décrire l'application de l'algorithme du procédé de l'invention à l'exemple précité de la simulation de trafic aérien pour la seule création du niveau « analyse du problème ». Le niveau suivant, non décrit ici pour des raisons de simplification, est obtenu de façon analogue.
La première phase est la création du modèle d'analyse par une première itération de l'algorithme (Cf :Figure 4)
1ère application de la règle R^« Spécification du problème » Soient : • S, le « Descriptif d'avion » : c'est l'ensemble des éléments source représentant un descriptif d'avion comportant un nom, un nombre de passagers ainsi qu'un nombre de moteurs. • R, la règle R1 de création du niveau de conception « Analyse du problème ».
Il n'y a pas de lien issu de S, il faut donc créer les éléments cibles, le Lien S.C.R et les paramètres associés. On procède de la façon suivante :
• A partir du descriptif d'avion comportant le nom A3XX, un nombre de passagers de 600 et un nombre de moteurs de 4 , l'algorithme consiste à :
a. créer un répertoire stéréotypé « projet » portant le nom de l'avion du descriptif (soit A3XX) comprenant : i. une classe stéréotypée « avion » nommée A3XX, ii. une classe stéréotypée « moteur » de nom « réaction », iii. une classe stéréotypée « passager » de nom «personne ». b. créer un lien de composition nommé « motorisation » entre la classe stéréotypée « avion » et la classe stéréotypée « moteur » avec une cardinalité 1 côté classe stéréotypée « avion », et 4 côté classe stéréotypée « moteur ». c. créer un lien d'association nommé « passager » entre la classe stéréotypée « avion » et la classe stéréotypée « passager » avec une cardinalité 1 côté classe stéréotypée « avion », 600 côté classe stéréotypée « passager ».
• Créer le lien de traçabilité Lien S,C,R (avec S= « Descriptif d'avion », C = répertoire A3XX stéréotypé « projet », classe A3XX, classe réaction, classe personne, le lien de composition et le lien d'association précédemment créés avec leurs cardinalités respectives et R = R^.
• Il n'y a pas de paramètres à la règle R (le concepteur n'explicite aucun choix, car la règle n'a besoin d'aucune information externe) ;
On suppose maintenant que le concepteur procède au raffinement du modèle d'analyse (Fig 5 : Raffinement manuel de l'analyse): Il ajoute deux méthodes « atterrir » et « décoller » à la classe nommée A3XX
• Il ajoute un attribut « puissance » à la classe nommée Réaction • Il ajoute deux attributs « nom » et « nationalité » à la classe nommée Personne • Il ajoute une classe « Réservation » comprenant trois attributs « départ », « arrivée » et « numéro de vol »
• Il ajoute un lien de composition entre la classe Passager et la classe Réservation de cardinalité 1.
On suppose ensuite que le concepteur procède à la modification d'une information du niveau « spécification du problème » :
• Il remplace le nom A3XX par A380.
On va maintenant exposer la façon dont le procédé de l'invention réalise la mise à jour des modèles, lors d'une deuxième itération de l'algorithme. Le résultat de la mise à jour est illustré (Fig 6 : Modification de la spécification et mise à jour automatique):
2ème application de la règle Ri « Spécification du problème » Soient : • S le « Descriptif d'avion » : c'est un élément source représentant un descriptif d'avion comportant un nom, un nombre de passagers ainsi qu'un nombre de moteurs. • R la règle R1 de création du niveau de conception « Analyse du problème ». II existe un Lien S,C,R issu de S. Il faut donc appeler le sous- programme à partir du Liens.c.R existant. L'algorithme consiste à :
1. Saisir au niveau analyse le répertoire « projet » lié au descriptif d'avion et le mettre à jour si nécessaire selon les caractéristiques de S via R; faire la mise à jour du LienS,C,R : le répertoire A3XX est renommé A380
2. Saisir au niveau analyse la classe stéréotypée « avion » liée au descriptif d'avion et la mettre à jour si nécessaire selon les caractéristiques de S via R; faire la mise à jour du LienS.C.R : la classe A3XX est renommée A380 3. Saisir au niveau analyse le lien de composition nommé « motorisation » lié au descriptif d'avion et le mettre à jour les cardinalités si nécessaire selon les caractéristiques de S via R; faire la mise à jour du LienS.Cn : les cardinalités restent inchangées
4. Saisir au niveau analyse le lien d'association nommé « passager » lié au descriptif d'avion et le mettre à jour les cardinalités si nécessaire selon les caractéristiques de S via R; faire la mise à jour du LienS.C.R : les cardinalités restent inchangées.

Claims

REVENDICATIONS
1. Procédé de développement automatisé avec règles de transformation permettant de passer d'un modèle à un autre, avec mise à jour, selon lequel on construit la spécification d'une solution répondant à la spécification d'un problème en réalisant un document d'analyse, puis un document de conception, et enfin en réalisant le programme résultant des étapes de conception, caractérisé par le fait que l'on associe à chaque élément de modèle produit automatiquement au moins un lien de traçabilité avec l'ensemble des éléments à partir duquel il est issu selon la règle de transformation, ce lien de traçabilité étant destiné à la prise en compte des nouvelles informations introduites manuellement en cours de développement.
2. Procédé selon la revendication 1 , caractérisé par le fait que les éléments manipulés sont des éléments UML.
3. Procédé selon la revendication 2, caractérisé par le fait que l'on utilise une « dependency » UML pour établir le lien de traçabilité.
4. Procédé selon la revendication 2, caractérisé par le fait qu'il est utilisé pour mettre en œuvre des « design pattems ».
EP04712052A 2003-03-03 2004-02-18 Procede de developpement automatise avec mise a jour Withdrawn EP1599795A2 (fr)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR0302558 2003-03-03
FR0302558A FR2852117A1 (fr) 2003-03-03 2003-03-03 Procede de developpement automatise avec mise a jour
PCT/EP2004/050151 WO2004079477A2 (fr) 2003-03-03 2004-02-18 Procede de developpement automatise avec mise a jour

Publications (1)

Publication Number Publication Date
EP1599795A2 true EP1599795A2 (fr) 2005-11-30

Family

ID=32865188

Family Applications (1)

Application Number Title Priority Date Filing Date
EP04712052A Withdrawn EP1599795A2 (fr) 2003-03-03 2004-02-18 Procede de developpement automatise avec mise a jour

Country Status (6)

Country Link
US (1) US20060248502A1 (fr)
EP (1) EP1599795A2 (fr)
CN (1) CN1757013A (fr)
CA (1) CA2517775A1 (fr)
FR (1) FR2852117A1 (fr)
WO (1) WO2004079477A2 (fr)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9292410B2 (en) * 2011-11-06 2016-03-22 International Business Machines Corporation Using traceability links strength for software development integrity monitoring
US9021419B2 (en) * 2013-02-15 2015-04-28 Oracle International Corporation System and method for supporting intelligent design pattern automation
CN105243949A (zh) * 2015-11-09 2016-01-13 河南平原光电有限公司 半导体激光器信息场模拟器

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2351165B (en) * 1999-06-18 2003-11-05 Univ London Method and apparatus for monitoring and maintaining the consistency of distributed documents

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2004079477A2 *

Also Published As

Publication number Publication date
WO2004079477A2 (fr) 2004-09-16
WO2004079477A3 (fr) 2004-11-11
US20060248502A1 (en) 2006-11-02
FR2852117A1 (fr) 2004-09-10
CA2517775A1 (fr) 2004-09-16
CN1757013A (zh) 2006-04-05

Similar Documents

Publication Publication Date Title
CN104573162B (zh) 一种汽车悬架dmu模型参数化设计方法
EP1880325B1 (fr) Méthode dynamique de génération de documents xml á partir d'une base de données
EP0453371B1 (fr) Procédé interactif de production de logiciel en code source modélisant un ensemble complexe de modules fonctionnels
FR2679353A1 (fr) Procede de mise en page de documents structures.
CN114089956B (zh) 一种基于需求模型的微服务拆分方法
CN114118417A (zh) 一种多模态预训练方法、装置、设备及介质
WO2015185328A1 (fr) Procédé informatisé et successions de signaux pour un programme de réutilisation de configurations logicielles exécutables pour systèmes logiciels ainsi que système informatique et programme informatique avec code programme pour mettre en œuvre le procédé
EP1788497A1 (fr) Motif de conception et procédé de transformation d'un modèle objet
EP1599795A2 (fr) Procede de developpement automatise avec mise a jour
KR102654017B1 (ko) 생성형 순환 신경망 모델을 이용한 영상 개선과 학습데이터 생성을 통합하는 방법 및 그 장치
US20240378351A1 (en) System and method for shape optimization
CN109710300A (zh) 一种标定与诊断软件版本管理的软件构架
FR2701580A1 (fr) Procédé d'administration d'applications avec des protocoles standards.
US20140172500A1 (en) Computer-implemented method and process management system for dynamically adapting processes
EP1612668A1 (fr) Procédé de transformation de code informatique et produit/programme d'ordinateur pour la mise en oeuvre d'un tel procédé
FR2937770A1 (fr) Procede de creation d'une surface non axisymetrique
US20110107296A1 (en) Model-operative pattern representation harvesting using an automated exemplar-directed approach
US20250238572A1 (en) System and method for managing components of a vehicle system
KR20210065230A (ko) 영상에서의 안개 제거 방법 및 장치
US20250384603A1 (en) Method for Image Generation, Electronic Device and Non-transitory Storage Medium
JPH04220768A (ja) テキスト変換方法
CN121543637A (zh) 基于预测残差引导的扩散模型迁移方法及相关装置
DE102025107947A1 (de) Editieren digitaler bilder unter verwendung von ausführbarem code, der von large language models aus eingaben natürlicher sprache generiert wird
REDDY et al. THE NEW WAVE OF AUTOMATED MACHINE LEARNING
CN120876636A (zh) 背景保留图像编辑方法、装置、电子设备及程序产品

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20050823

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LI LU MC NL PT RO SE SI SK TR

AX Request for extension of the european patent

Extension state: AL LT LV MK

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20070227

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20090616