EP1599795A2 - Automated development method with update - Google Patents

Abstract

The invention relates to an automated development method with an update, consisting of several design steps with transformation rules making it possible to pass from one step to the other. The invention is characterized in that at least one traceability link is associated with each element which is produced automatically during the design, said link being based on the element from which it originates, according to a transformation rule.

Description

 AUTOMATED DEVELOPMENT METHOD WITH UPDATE

The present invention relates to an automated development method with updating.

Developing a complex system requires different stages of problem solving and incremental design. The objective is to build the specification of a solution responding to the specification of a problem. In the software domain, the specification of a customer need gives rise to the production of an analysis document, then of a design document and ends with the production of the expected program. Analysis, design and implementation allow you to incrementally build a solution by explaining the construction process. These different stages facilitate the maintenance of the program which results from the different design stages and allow the software thus produced to evolve according to the customer's needs.

Whatever the field of application, it is possible to formalize, with the appropriate languages, the stages of construction as well as their results, which will be called design levels hereinafter. A design level can, for example, be expressed as UML models

(Unified Modeling Language).

It is possible to partially generate a design level based on the design level that precedes it from transformation rules. New information must however be introduced manually to enrich the newly created model and refine the concepts so as to converge towards the level of detail expected for the realization of the solution.

The incremental approach is illustrated using a very simplified example taken in the area of air traffic simulation, and shown diagrammatically in Fig 1: First development. This figure has three design levels: 1. 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.

3. The “design of a solution” level is much more “technical”. The language used is no longer linked to the aviation field. We are no longer interested in the concepts of aircraft or passengers. We emphasize the notion of actor (computer object triggering processing) that must be simulated. It is at this level that the actions to be executed are precisely defined in a language close to that directly understandable by the computer (for example C ++).

In Fig 1: First development, all the elements in thin line or in italics explain the information added manually. All the information shown in bold or in bold is obtained automatically by applying the transformation rules

R-i to Rg following:

• Creation of the “Analysis of the problem” design level: Ri: For any aircraft description comprising a name, a number of passengers and a number of engines, the algorithm consists of: at. create a stereotypical “project” directory on behalf of the aircraft (name) including: i. a stereotypical class “airplane” named “name” (name referring to the name of airplane), ii. a stereotypical class "engine" with the name

"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". • Creation of the design level "Conception of a solution": R ₂ : For any stereotyped repertoire "project" at the level "problem analysis" the algorithm consists of: a. create a stereotyped “Design” directory at the “design of a solution” level having the same name as the name of the stereotyped “project” directory at the design level “problem analysis”; b. create an “Actor” stereotypical “Active” class;

R ₃ : 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 ₅ : 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;

Re: 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 ₈ : 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. During the re-application of the rules, 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.

• This conservation of information is not carried out with known methods. It is essential for maintaining and developing the design levels, and can only be done by coupling the transformation with the traceability, this coupling being the subject of the present invention, as detailed below.

By way of example, to illustrate the main drawback of the known methods, it is proposed to change the name of the aircraft A3XX to A380 at the level "Description specification of the problem", the name of A380 having been finally chosen, then to re-apply the previously mentioned rules. By applying the only known mechanism of transformation rules, we obtain the models presented in Fig 2: Non-conservative transformation. All the occurrences of the name A3XX have been correctly replaced by A380 but all the information added manually (information in italics and in thin lines on the various figures), during the first iteration, at the level of "Analysis of the problem" and "Design of a solution ”are lost. This solution is unacceptable: in order not to lose all their work, the designer must give up the use of transformation rules and manually pass on the modification (the name of the aircraft) to all the underlying design levels, where it is necessary and with all the risks of inconsistencies that this represents. To carry out this work, the designer can, using existing tools, establish traceability elements to link all occurrences of the name A3XX. These links will allow him to locate all the modifications to be made during the name change, but these modifications will remain at his expense. The transformation and traceability mechanisms are managed independently.

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.

According to another characteristic of the invention, the elements used are UML elements. Advantageously, a UML "dependency" is used to establish the traceability link, the "dependency" being as defined at OMG in the definition of the UML language.

According to yet another characteristic of the invention, the method of the invention is used to implement "Design patterns". The present invention will be better understood on reading the detailed description of an embodiment, taken by way of nonlimiting example and illustrated by the appended drawing, in which:

FIG. 1, cited above, is a block diagram of a first development of an air traffic simulation program,

FIG. 2, also cited above, 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),

- Figure 5 is a block diagram illustrating the manual enrichment of the level of analysis by the designer (information in italics and in thin lines).

- Figure 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. This connection

(source elements, target elements, and parameters of the rule) only exists during the application of the rule.

The invention proposes to couple a traceability mechanism with a transformation mechanism. For this, we add elements to the rules which:

• explain the complete traceability between elements of a source design level to the different elements of a target design level,

• explain the parameters of the rule (information provided by the designer necessary for the application of the rules),

• allow the update of a target design level from a source design level without impacting elements not resulting from the application of a rule during a previous transformation. 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.

We will now describe in detail a mode of implementation of the method of the invention. 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. We call this link, traceability link. It is a logical link, which links n source elements, to m target elements. Definitions:

Let

• R: a transformation rule

• S: a set of elements of the source model (level N) • C: a set of elements of the target model (N + 1), coming from S, by applying the rule R,

• PARAMs, R: parameter of the R rule applied to S. Obtaining these parameters may require a dialogue with the designer.

• 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. The algorithm for implementing the process of the invention comprises the following three parts:

Conservative transformation algorithm:

For any set S to which the rule R applies If Link S, C, R then exists

Update of C and Links Γ. R Otherwise

Creation of C. du Lien s Γ. R and PARAMs,

Update of C, and Links r. R

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 ^.

Creation of C. of the link _S , Γ., And of PARAMS_R:

Creation then assignment (i.e. fixing of values) of C elements by application of

R as well as creation of the link s.c.Rβt of the PARAMs parameters, R (possibly empty).

We will now describe the application of the algorithm of the method of the invention to the aforementioned example of air traffic simulation for the sole creation of the "problem analysis" level. The next level, not described here for reasons of simplification, is obtained in a similar manner.

The first phase is the creation of the analysis model by a first iteration of the algorithm (Cf: Figure 4)

1st application of rule R ^ "Specification of the problem" Let: • S, the "Airplane description": this is the set of source elements representing an airplane description including a name, a number of passengers and 'a number of motors. • R, the rule R1 for creating the design level "Problem analysis".

There is no link from S, so you have to create the target elements, the S.C.R Link and the associated parameters. We proceed as follows:

• From the aircraft description comprising the name A3XX, a number of passengers of 600 and a number of engines of 4, the algorithm consists of:

at. create 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".

• Create the traceability link Link S, C, R (with S = "Aircraft description", C = stereotypical A3XX directory "project", class A3XX, reaction class, person class, the composition link and the previously created association with their respective cardinalities and R = R ^.

• There are no parameters to the rule R (the designer does not explain any choice, because the rule does not need any external information);

We now suppose that the designer proceeds to the refinement of the analysis model (Fig 5: Manual refinement of the analysis): He adds two methods "landing" and "taking off" to the class named A3XX

• It adds an attribute “power” to the class named Reaction • It adds two attributes “name” and “nationality” to the class named Person • It adds a class "Reservation" comprising three attributes "departure", "arrival" and "flight number"

• It adds a composition link between the Passenger class and the Cardinality Reservation 1 class.

It is then supposed that the designer proceeds to modify information of the level "specification of the problem":

• It replaces the name A3XX with A380.

We will now explain how the method of the invention updates the models, during a second iteration of the algorithm. The result of the update is illustrated (Fig 6: Modification of the specification and automatic update):

2nd application of the rule Ri "Specification of the problem" Let: • S be the "Aircraft description": it is a source element representing an aircraft description including a name, a number of passengers and a number of engines . • R the rule R1 of creation of the level of design "Analysis of the problem". There exists a Link S, C, R from S. We must therefore call the subroutine from Links.c. _R existing. The algorithm consists of:

1. Enter the “project” directory linked to the aircraft description at the analysis level and update it if necessary according to the characteristics of S via R; update the LinkS, C, R: the A3XX directory is renamed A380

2. Enter at the analysis level the stereotypical class “airplane” linked to the airplane description and update it if necessary according to the characteristics of S via R; update LienS.CR: class A3XX is renamed A380 3. Enter at the analysis level the composition link called "engine" linked to the aircraft description and update the cardinalities if necessary according to the characteristics of S via R; update the LienS.Cn: the cardinalities remain unchanged

4. Enter the association link named “passenger” linked to the aircraft description at the analysis level and update the cardinalities if necessary according to the characteristics of S via R; update the LienS.C.R: the cardinalities remain unchanged.

Claims

1. Process of automated development with transformation rules allowing to pass from a model to another, with update, according to which one builds the specification of a solution answering the specification of a problem by realizing a document of analysis, then a design document, and finally by carrying out the program resulting from the design stages, characterized by the fact that each model element is automatically associated with at least one traceability link with all the elements from from which it originates according to the transformation rule, this traceability link being intended to take into account new information manually introduced during development. 2. Method according to claim 1, characterized in that the elements handled are UML elements. 3. Method according to claim 2, characterized in that one uses a "dependency" UML to establish the traceability link. 4. Method according to claim 2, characterized in that it is used to implement "design pattems".