WO2005069127A2 - Procede de remontee automatique des exigences de modeles uml et de leur mise a jour - Google Patents

Procede de remontee automatique des exigences de modeles uml et de leur mise a jour Download PDF

Info

Publication number
WO2005069127A2
WO2005069127A2 PCT/EP2004/053341 EP2004053341W WO2005069127A2 WO 2005069127 A2 WO2005069127 A2 WO 2005069127A2 EP 2004053341 W EP2004053341 W EP 2004053341W WO 2005069127 A2 WO2005069127 A2 WO 2005069127A2
Authority
WO
WIPO (PCT)
Prior art keywords
uml
requirements
doors
module
model
Prior art date
Application number
PCT/EP2004/053341
Other languages
English (en)
Other versions
WO2005069127A3 (fr
Inventor
Arnaud Bailleul
Eric Halbeher
Original Assignee
Thales
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 filed Critical Thales
Priority to US10/583,367 priority Critical patent/US20070168921A1/en
Publication of WO2005069127A2 publication Critical patent/WO2005069127A2/fr
Publication of WO2005069127A3 publication Critical patent/WO2005069127A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/10—Requirements analysis; Specification techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F30/00—Computer-aided design [CAD]

Definitions

  • the present invention relates to a method for automatically raising the requirements of UML models created by a modeling tool, and for updating them.
  • a modeling tool such as "RHAPSODY” from the company 1-LOGEX.
  • Modeling requires taking into account requirements, and for this purpose, we have a requirements management tool such as "DOORS" from the company TELELOGIC.
  • DOORS requirements management tool
  • the present invention relates to a process for automatically escalating the requirements of UML models to a requirements management tool to allow their updating, without limitation on the laying of requirements and their number.
  • the method according to the invention is characterized in that the requirements are created during the creation of the elements of the UML model, that once the model is stabilized, the requirements entered are exported to the requirements management tool in the model and a navigation module is automatically created containing all the UML objects pointed to by at least one requirement and a level n requirements module.
  • the level n requirements module is linked to another upstream level n + 1 requirements module defined above.
  • - Figure 1 is a simplified block diagram of an example of implementation of the method of the invention
  • - Figure 2 is a diagram illustrating the first import of a UML model into a requirements manager, according to the method of the invention
  • - Figure 3 is a diagram illustrating a new import, under the same conditions (import level 1) as in Figure 2
  • - Figure 4 is a diagram illustrating a new import of a UML model, but at a different level (level 2) from that of Figure 3
  • - Figure 5 is a diagram illustrating the automatic placement of traceability links from the module to other DOORS modules according to the method of the invention
  • - Figure 6 is a four-step diagram, illustrating the successive operations occurring during a new iteration of importing a UML model into a manager 'requirements, according to the method of the invention
  • - Figures 7 and 8 are diagrams showing two states of a Re
  • UML which in this case is the “DOORS, a utility workshop (3) tool, which is here“ DOORS Custom ”from the company THALES ANIONICS” and a universal connector for inter-tool connection (4) "PAPEETE” (subject to a patent application from THALES). Importing UML models into the tool
  • DOORS there is creation of two modules in DOORS: - A module (5) of UML_DOORS Requirements corresponding to the level of specification (level 1 for the example shown). This DOORS module contains all of the UMLJDOORS Requirements which represent the UML Requirements stereotyped with the level of specification chosen during the import. This module 5 contains here the level 1 requirements of the model. These requirements are, for this example: HLR 01, LLR 01 andHLR_03. - A UML navigation module (UML Surrogate Module) (6): this DOORS module contains a representation of all the UML elements of the model created in RHAPSODY. This representation is in the form of a reference to UML elements.
  • UML navigation module UML Surrogate Module
  • the aim of this module is to allow navigation between RHAPSODY and DOORS (as described in the “DOORS Custom User Guide” manual). Subsequent imports of the same UML model can be of two different types. Or, as shown in the example in Figure 3, this is the same level of specification as before (level 1 in this case). In this case, both the UMLJDOORS Requirements Module and the UML Navigation Module are updated according to the modifications made to the UML model. Or, as shown in Figure 4, they relate to a different level of specification (level 2 in this case, for which these are the requirements HLR_02 and LLR 02).
  • UML_DOORS Requirements module corresponding to the level of specification selected (level 2) during the import and update of the UML navigation module according to the modifications made to the model.
  • the links between a UML-DOORS Requirement and its representation in the UML Navigation Module are created automatically when the UML model is imported into DOORS. These links allow navigation between .the two RHAPSODY and DOORS tools.
  • the creation of links to other DOORS requirements modules is carried out as follows. After having imported an RHAPSODY model into DOORS, it is possible to automatically create links between Requirements of the module created automatically and Requirements of another DOORS module or those of another module created automatically previously.
  • the method of the invention makes it possible to automatically return to DOORS all the traceability information entered in the UML model. It automatically organizes under DOORS all the process necessary for navigation between the two tools via the PAPEETE connector or an XML link (or equivalent). Finally, it automatically organizes all the updating of the modules during the various evolutions of the UML model.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Evolutionary Computation (AREA)
  • Geometry (AREA)
  • Software Systems (AREA)
  • Stored Programmes (AREA)

Abstract

La présente invention est relative à un procédé de remontée automatique des exigences de modèles UML et de leur mise à jour, et selon une caractéristique de l'invention, on crée les exigences lors de la création des éléments du modèle UML, que, lorsque le modèle est stabilisé, on l'exporte vers l'outil de gestion d'exigences, on crée ainsi, automatiquement, un module de navigation contenant tous les objets UML pointés par au moins une exigence et un module d'exigences de niveau n pouvant lui-même être lié par la suite à d'autres modules d'exigences. En particulier le lien avec le module d'exigence amont de niveau n+1 pourra être automatisé grâce l'utilitaire DOORS TREK « Create links by key ... ».

Description

PROCEDE DE REMONTEE AUTOMATIQUE DES EXIGENCES DE MODELES UML ET DE LEUR MISE A JOUR
La présente invention se rapporte à un procédé de remontée automatique des exigences de modèles UML créés par un outil de modélisation, et de leur mise à jour. Lorsque l'on modélise un projet, quel qu'il soit, on utilise actuellement, de façon préférentielle le langage UML, mis en œuvre dans un outil de modélisation, tel que « RHAPSODY » de la société 1-LOGEX. La modélisation nécessite la prise en compte d'exigences, et à cet effet, on dispose d'un outil de gestion d'exigences tel que « DOORS » de la société TELELOGIC. Toutefois, il n'existe aucun moyen permettant d'assurer la traçabilité des informations du modèle pour en informer l'outil de gestion d'exigences. La présente invention a pour objet un procédé de remontée automatique des exigences de modèles UML vers un outil de gestion d'exigences pour permettre leur mise à jour, et ce, sans limitation sur la pose d'exigences et leur nombre. Le procédé conforme à l'invention est caractérisé en ce que l'on crée les exigences lors de la création des éléments du modèle UML, qu'une fois le modèle stabilisé, on exporte vers l'outil de gestion d'exigences les exigences saisies dans le modèle et l'on crée automatiquement un module de navigation contenant tous les objets UML pointés par au moins une exigence et un module d'exigences de niveau n. Avantageusement, on lie le module d'exigences de niveau n à un autre module d'exigences amont de niveau n+1 défini précédemment. 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 est un bloc-diagramme simplifié d'un exemple de mise en œuvre du procédé de l'invention, - la figure 2 est un diagramme illustrant la première importation d'un modèle UML dans un gestionnaire d'exigences, selon le procédé de l'invention, - la figure 3 est un diagramme illustrant une nouvelle importation , dans les mêmes conditions (import niveau 1) qu'en figure 2, - la figure 4 est un diagramme illustrant une nouvelle importation d'un modèle UML, mais à un niveau différent (niveau 2) de celui de la figure 3, - la figure 5 est un diagramme illustrant la pose automatique de liens de traçàbilité depuis le module vers d'autres modules DOORS selon le procédé de l'invention, - la figure 6 est un diagramme en quatre étapes, illustrant les opérations successives intervenant lors d 'une nouvel le itération d'import d'un modèle UML dans un gestionnaire d'exigences, selon le procédé de l'invention, et - les figures 7 et 8 sont des diagrammes montrant deux états d'un module d'Exigences du gestionnaire d'exigences, respectivement avant et après une nouvelle importation, selon le procédé de l'invention. On a représenté en figure 1 les principaux éléments de l'architecture du système mettant en œuvre l'invention. Ces éléments sont : un modeleur UML (1), qui est, de préférence, l'outil « RHΛPSODY », un outil (2) de gestion d'Exigences
UML, qui est, dans le cas présent, l'outil « DOORS , un atelier d'utilitaires (3), qui est ici « DOORS Custom » de la société THALES ANIONICS » et un connecteur universel de connexion inter-outils (4) « PAPEETE » (faisant l'objet d'une demande de brevet de la société THALES). L'importation de modèles UML dans l'outil
DOORS depuis l'outil RHAPSODY se fait de la manière suivante.
Lors de la première importation d'un modèle UML de RHAPSODY vers DOORS
(voir figure 2), il y a création de deux modules dans DOORS: - Un module (5) d'Exigences UML_DOORS correspondant au niveau de spécification (niveau 1 pour l'exemple représenté). Ce module de DOORS contient l'ensemble des Exigences UMLJDOORS qui représentent les Exigences UML stéréotypées avec le niveau de spécification choisi lors de l'importation. Ce module 5 contient ici les exigences de niveau 1 du modèle. Ces exigences sont, pour cet exemple : HLR 01, LLR 01 etHLR_03. - Un Module de navigation UML (Surrogate Module UML) (6) : ce module de DOORS contient une représentation de l'ensemble des éléments UML du modèle créé dans RHAPSODY. Cette représentation est sous forme de référence vers les éléments UML. Ce module a comme objectif de permettre la navigation entre RHAPSODY et DOORS (comme exposé dans le manuel « DOORS Custom User Guide »). Les importations suivantes du même modèle UML peuvent être de deux types différents. Soit, comme représenté sur l'exemple de la figure 3, il s'agit du même niveau de spécification que précédemment (niveau 1 en l'occurrence). Dans ce cas, à la fois le Module d'Exigences UMLJDOORS et le Module de navigation UML sont mis à jour en fonction des modifications apportées au modèle UML. Soit, comme représenté en figure 4, ils portent sur un niveau de spécification différent (niveau 2 en l'occurrence, pour lequel il s'agit des exigences HLR_02 et LLR 02 ) . Dans ce cas, il y a création d'un module d'Exigences UML_DOORS correspondant au niveau de spécification sélectionné (niveau 2) lors de l'importation et mise à jour du Module de navigation UML en fonction des modifications apportées au modèle. Les liens entre une Exigence UML-DOORS et sa représentation dans le Module de navigation UML sont créés automatiquement lors de l'importation du modèle UML sous DOORS. Ces liens permettent la navigation entre .les deux outils RHAPSODY et DOORS. La création de liens vers d'autres modules d'exigences DOORS est réalisée de la façon suivante. Après avoir effectué une importation d'un modèle RHAPSODY dans DOORS, il est possible de créer automatiquement les liens entre des Exigences du module crée automatiquement et des Exigences d'un autre module DOORS ou celles d'un autre module crée automatiquement antérieurement. Cette création automatique de liens est effectuée avec l'utilitaire DOORS TREK « Create links by key ... ». Ainsi, comme représenté en figure 5, lors de l'importation du niveau de spécification X, on crée des liens de traçabilité entre le module d'Exigences de niveau X et, d'une part, le module d'exigences de niveau X-l, et d'autre part un module de niveau de spécification d'exigences tout à fait autre (SSS dans ce cas) . La gestion des modifications apportées aux exigences relatives au modèle UML est réalisée de la façon suivante. La gestion des modifications des exigences sous-entend la capacité de naviguer entre l'outil RHAPSODY et l'outil DOORS. En effet, il faut être capable d'analyser rapidement l'impact de modifications des exigences amont sur le modèle UML afin d'appliquer les modifications adéquates sur les éléments mis en cause par cet impact et inversement. Pour réaliser la modification d'Exigences UML_DOORS, il ne faut pas modifier sous DOORS les attributs des Exigences UML DOORS spécifiées dans les Exigences UML (comme expliqué dans le Guide de modélisation UML des exigences). Ces modifications ne doivent être effectuées que dans le modèle UML sous RHAPSODY. A la suite d'une modification d'Exigences DOORS, il faut pour chaque Exigence UML-JDOORS qui la raffine (comme expliqué dans le Guide DOORS) : 1. naviguer, à l'aide de l'outil de navigation DOORS/RHAPSODY, vers l'Exigence UML associée,
2. analyser l'impact sur la modélisation de la modification à effectuer,
3. mettre à jour le modèle
4. mettre à jour l'Exigence UML dans le modèle, 5. importer le modèle modifié sous DOORS,
6. mettre à jour les attributs de gestion des exigences sous DOORS, Toute modification de modèle doit être effectuée en prenant en compte les
Exigences UML qui ont une répercussion sur les éléments modifiés de manière à maintenir la cohérence entre les Exigences UML et le modèle UML. Pour ce faire, il faut consulter pour chaque élément UML modifié l'ensemble des
Exigences UML qui ont une répercussion sur lui, pour vérifier que ces exigences sont toujours coJ érentes avec la modification effectuée sur l'élément. Pour gérer les évolutions d'un modèle se traduisant par des modifications successives, on examine d'abord le mécanisme d'importations successives. L'importation d'un modèle UML sous DOORS est effectuée en plusieurs étapes. Ces étapes sont invisibles pour l'utilisateur, car elles sont effectuées en une seule fois lors de l'importation. On a illustré en figure 6 les principales étapes de ce mécanisme d'importations successives. Cette figure comporte quatre diagrammes (référencés 1 à 4). A l'état initial (1), on a, dans DOORS, un module Exigences UMLJDOORS lié à un module de navigation UML (par des liens de navigation), ces modules générés automatiquement lors d'un import antérieur sont qualifiés d' « anciens ». Lorsqu'arrive une demande d'importation du modèle UML visant une mise à jour de ces deux modules, les actions suivantes sont engagées : - création de deux nouveaux modules (2): o un Module Exigences UMLJDOORS contenant l'ensemble des Exigences UML DOORS correspondant à toutes les Exigences UML contenues dans le nouveau modèle UML importé, o un module de navigation UML représentant le nouveau modèle UML, - suppression de l'ancien module de navigation UML et de tous les éléments DOORS le concernant. (3), - analyse des mises à jour à effectuer entre les deux Modules Exigences UMLJDOORS, - mise à jour de l'ancien Module Exigences UMLJDOORS (4),- - suppression du nouveau Module Exigences UML_DOORS;s(4), - création des liens de navigation entre l'ancien Module Exigences UML_DOORS et le nouveau Module de navigation UML. L'utilisateur doit ensuite mettre à jour les liens de traçabilité avec les exigences amont. Cette étape n'est pas incluse dans rimportation du modèle UML, mais doit être effectuée séparément après chaque importation à l'aide de l'utiUtaire DOORS TREK « Create links by key ... ». La gestion des évolutions peut concerner ensuite l'ajout d'exigences. Si l'on ajoute une Exigence UML dans le modèle, il y aura, lors de l'importation suivante, pour un même niveau de spécification, et un même modèle UML, création d'un nouvel objet DOORS dans le Module de navigation UML et dans le Module de navigation UML correspondants. A titre d'exemple simplifié, on a représenté en figure 7 l'état du Module Exigences UML_DOORS avant une nouvelle importation, et qui comporte les Exigences EXIOl à EXI_04 (en version vl). On a représenté en figure 8 l'état de ce Module après une nouvelle importation, EXI 02 étant modifiée (versions vl et v2 coexistantes), et avec une nouvelle Exigence EXI 05 (version v2). De même, si une Exigence UML déjà importée lors d'une précédente importation est supprimée dans le modèle, lors de l'importation suivante, l'Exigence UML- DOORS correspondant à l'Exigence UML , ne sera pas supprimée du Module Exigences UML DOORS, mais prendra le statut « OBSOLETE » et tous ses liens DOORS seront détruits. Si une Exigence UML déjà importée lors d'une précédente importation est modifiée dans le modèle, il y aura, lors de rimportation suivante, : - création d'une nouvelle Exigence UML-DOORS correspondant à l'Exigence UML - création d'un lien entre l'ancienne et la nouvelle Exigence UML-DOORS - transfert des liens entrants et sortants de l'ancienne vers la nouvelle Exigence UML-DOORS - mise à jour du numéro de version sur la nouvelle Exigence UML-DOORS par rapport à l'ancienne.
On obtient ainsi un historique des modifications d'exigences. En conclusion, le procédé de l'invention permet de remonter automatiquement sous DOORS toutes les informations de traçabilité rentrées dans le modèle UML. Il organise automatiquement sous DOORS tout le processus nécessaire à la navigation entre les deux outils via le connecteur PAPEETE ou un lien XML (ou équivalent) . Enfin il organise automatiquement toute la mise à jour des modules lors des différentes évolutions du modèle UML.

Claims

REVENDICATIONS
1. Procédé de remontée automatique des exigences de modèles UML 5 créées par un outil de modélisation, et de leur mise à jour , caractérisé en ce que l'on crée les exigences lors de la création des éléments du modèle UML, que, lorsque le modèle est stabilisé, on exporte vers l'outil de gestion d'exigences les exigences saisies dans le modèle, et que l'on crée , automatiquement, un module de navigation contenant 10 tous les objets UML pointés par au moins une exigence et un module d'exigences de niveau n.
2. Procédé selon la revendication 1, caractérisé en ce qu'on lie le module d'exigences de niveau n à un autre module d'exigences amont de niveau n+1 défini précédemment.
15 3. Procédé selon la revendication 1 ou 2, caractérisé en ce que, lors de modifications d'exigences, on effectue ces modifications dans le modèle UML, avec l'outil de modélisation.
4. Procédé selon l'une des revendications précédentes, caractérisé en ,%l. ce que l'outil de modélisation est « RHAPSQÇ)Y » et que l'outil de 20 gestion des exigences est « DOORS ».
5. Procédé selon la revendication 4, caractérisé en ce que lors d'importations successives, on réalise les étapes suivantes : - création de deux nouveaux modules : " un Module Exigences UMLJDOORS contenant l'ensemble 25 des Exigences UMLJDOORS correspondant à toutes les Exigences UML contenues dans le modèle UML importé, " un module de navigation UML représentant le nouveau modèle UML, - suppression de l'ancien module de navigation UML et de tous les 30 éléments DOORS le concernant , - analyse des mises à jour à effectuer entre les deux Modules Exigences UMLJDOORS, - mise à jour de l'ancien Module Exigences UMLJDOORS, - suppression du nouveau Module Exigences UMLJDOORS, - création des liens de navigation entre l'ancien Module Exigences UMLJDOORS et le nouveau Module de navigation UML.
6. Procédé selon la revendication 4 ou 5, caractérisé en ce que si une Exigence UML déjà importée lors d'une précédente importation est modifiée dans le modèle, il y aura, lors de l'importation suivante, : o création d'une nouvelle Exigence UML-DOORS correspondant à l'Exigence UML o création d'un lien entre l'ancienne et la nouvelle Exigence UML- DOORS o transfert des liens entrants et sortants de l'ancienne vers la nouvelle Exigence UML-DOORS o mise à jour du numéro de version sur la nouvelle Exigence UML- DOORS par rapport à l'ancienne.
PCT/EP2004/053341 2003-12-19 2004-12-08 Procede de remontee automatique des exigences de modeles uml et de leur mise a jour WO2005069127A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/583,367 US20070168921A1 (en) 2003-12-19 2004-12-08 Method for automatic recovery of uml model requirements and updating thereof

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0315036A FR2864285A1 (fr) 2003-12-19 2003-12-19 Procede de remontee automatique des exigences de modeles uml et de leur mise a jour
FR0315036 2003-12-19

Publications (2)

Publication Number Publication Date
WO2005069127A2 true WO2005069127A2 (fr) 2005-07-28
WO2005069127A3 WO2005069127A3 (fr) 2006-08-24

Family

ID=34630367

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2004/053341 WO2005069127A2 (fr) 2003-12-19 2004-12-08 Procede de remontee automatique des exigences de modeles uml et de leur mise a jour

Country Status (3)

Country Link
US (1) US20070168921A1 (fr)
FR (1) FR2864285A1 (fr)
WO (1) WO2005069127A2 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2863386A1 (fr) 2003-12-09 2005-06-10 Thales Sa Procede de generation de code c a partir de specifications uml
FR2864284B1 (fr) * 2003-12-19 2006-04-21 Thales Sa Procede de verification de regles sur les modeles uml
US7908583B2 (en) * 2005-12-29 2011-03-15 International Business Machines Corporation Evidentiary enrichment of traceability links between software specification requirements
US8245182B2 (en) * 2008-04-14 2012-08-14 International Business Machines Corporation Class selectable design sharing
US9176937B2 (en) * 2012-04-05 2015-11-03 International Business Machines Corporation Ensuring user interface specification accurately describes user interface after updates to user interface
US10579340B2 (en) * 2012-06-06 2020-03-03 International Business Machines Corporation Model element characteristic preservation in modeling environments

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2353613A (en) * 1999-08-24 2001-02-28 Quality Systems & Software Ltd Information processor stores information objects and associated attributes

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2000194539A (ja) * 1998-12-24 2000-07-14 Nec Corp ソフトウェアインストールシステムおよびソフトウェアインストール方法
EP1205841A1 (fr) * 2000-10-26 2002-05-15 Ebeon Research & Development Limited Procédé pour le développement du logiciel
US8479189B2 (en) * 2000-11-17 2013-07-02 Hewlett-Packard Development Company, L.P. Pattern detection preprocessor in an electronic device update generation system
US7480893B2 (en) * 2002-10-04 2009-01-20 Siemens Corporate Research, Inc. Rule-based system and method for checking compliance of architectural analysis and design models
US7003534B2 (en) * 2002-11-18 2006-02-21 Innopath Software, Inc. Generating difference files using module information of embedded software components
US7546575B1 (en) * 2003-06-09 2009-06-09 Dillman Frederick J System and method for using blueprints to provide a software solution for an enterprise
US20050091642A1 (en) * 2003-10-28 2005-04-28 Miller William L. Method and systems for learning model-based lifecycle diagnostics
US20050166178A1 (en) * 2004-01-23 2005-07-28 Masticola Stephen P. Process for global software development

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2353613A (en) * 1999-08-24 2001-02-28 Quality Systems & Software Ltd Information processor stores information objects and associated attributes

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"I-Logix, Inc. - Rhapsody Overview" INTERNET, 23 août 2000 (2000-08-23), XP002972804 *
EDER K ET AL: "Requirements engineering in development of automotive and aeronautical systems" ELEKTRONIK (GERMANY), ELEKTRONIK, 23 JULY 2002, WEKA-FACHZEITSCHRIFTEN, GERMANY, vol. 51, no. 15, 23 juillet 2002 (2002-07-23), pages 74-77, XP002293367 ISSN: 0013-5658 *
RICHARD WATSON: "Smarter Requirements Managment with Intelligent Traceability"[Online] 31 juillet 2003 (2003-07-31), pages 1-16, XP002293366 Extrait de l'Internet: URL:http://www.telelogic.com/download/pape r/Intelligent_Traceability_White_Paper.pdf ?CFID=8181463&CFTOKEN=19802674fe2fd9da-441 DFD22-3477-99FC-6EC39F28241538A1> [extrait le 2004-08-19] *

Also Published As

Publication number Publication date
US20070168921A1 (en) 2007-07-19
WO2005069127A3 (fr) 2006-08-24
FR2864285A1 (fr) 2005-06-24

Similar Documents

Publication Publication Date Title
WO1995012855A1 (fr) Systeme de controle d'une base de donnees relationnelle selon une logique d'acces orientee objet limitant le nombre des acces a ladite base de donnees, et procede correspondant
WO2016177963A1 (fr) Procédé, programme d'ordinateur et système pour la commande d'un déplacement d'un agent navigant dans un environnement organisé en réseau
FR2946160A1 (fr) Systeme et procede pour editer et commander des comportements d'un robot mobile.
CA2506487A1 (fr) Systeme et procede de gestion de tables de donnees
FR2907944A1 (fr) Procede et dispositifs d'aide a la modelisation d'objets 3d.
Cardinale On action, embeddedness, and institutional change
EP2297681A1 (fr) Procede de gestion de donnees pour atelier oriente service collaboratif
WO2005069127A2 (fr) Procede de remontee automatique des exigences de modeles uml et de leur mise a jour
CA2113382C (fr) Procede d'administration d'applications avec des protocoles standards
FR2931272A1 (fr) Procede d'import export de donnees d'une base de donnees
WO2009147311A1 (fr) Procede de gestion de processus dans un atelier oriente service collaboratif
EP3881515B1 (fr) Système de supervision formelle de communications
Puente et al. Wiki refactoring as mind map reshaping
WO2010119208A1 (fr) Procede d'assistance au developpement ou a l'utilisation d'un systeme complexe
EP1588351A1 (fr) Production automatique d'interfaces de reconnaissance vocale pour un domaine d'application
EP3475847B1 (fr) Serveur de statistiques pour optimisation de requêtes client-serveur
EP1262867A1 (fr) Procédé d'implémentation d'une pluralité d'interfaces d'objets
FR3043813A1 (fr) Procede de mise a jour d'un enregistrement dans une base de donnees par un dispositif de traitement de donnees
Palacio Distributed Data Systems with Azure Databricks: Create, deploy, and manage enterprise data pipelines
EP1473627A2 (fr) Procédé pour la modélisation de données référentielles et son utilisation pour la localisation de données référentielles dans un système d'informations
EP3874368B1 (fr) Executer des portions de code sur des ressources d´execution
FR2943155A1 (fr) Procede et systeme collaboratif de modifications d'applications numeriques en reseau
FR2690803A1 (fr) Appareil de simulation de protocole permettant de vérifier dynamiquement un protocole de communication, et procédé associé.
WO2012149977A1 (fr) Procede et systeme correspondant de generation d'une application logicielle manipulant des donnees structurees.
EP2746977A1 (fr) Procédé de génération d'une version d'un modele de supervision d'un système d'information

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPEN Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed from 20040101)
WWE Wipo information: entry into national phase

Ref document number: 2007168921

Country of ref document: US

Ref document number: 10583367

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase
WWP Wipo information: published in national office

Ref document number: 10583367

Country of ref document: US