Application software generation and language for software description

Translation of description of equivalent WO 2004013800 A2

GENERATION SOFTWARE APPLICATION CODE LANGUAGE AND COMPUTER SOFTWARE DESCRIPTION

TECHNICAL AREA

The present invention relates to a generation software computer code of at least part of a computer application from a description of that part of the computer application. The invention also concerns a software description language, including computer application modeling language object types. In this description, we use the following terms with the meanings specified:

- "Computer program" means any program or set of programs intended to work together, which aims to provide services to their users; an application consists of:

- Interfaces, that is to say, interaction with the outside world to the application (human users, other information systems)

- Its treatment, that is to say its inner workings, its algorithms,

- And its data, that is to say of all its information structures stored in memory or on persistent media such as a hard disk.

- "Technical architecture": these are all technologies used to produce a computer application and allocation rules for allocating the different parts of this application on these different technologies and communications between these modes technologies.

- "Class" means the notion of class commonly manipulated in modeling formalism and object-oriented programming languages ​​is to say, data aggregation and processing (respectively called attributes and methods) to work together in a computer application.

- "Client" means the service user that he does not define himself. A client uses the services provided by servers. By extension, we speak of client applications, client interfaces, etc. - "Source code": text written in a programming language or description which is then compiled into machine code to be executed by a hardware computing platform, or interpreted by a software environment or interpretive materials.

- "Compiled code" result of the compilation process of source code.

- "Code": means either the source code or the compiled code. - "Compilation": Translation of Action a description expressed in a programming language to the native language of a hardware computing platform, before his execution by the hardware computing platform. - "Server" means a provider of a service. The services provided by a server can be used by customers. By extension, it is called server applications, server interfaces, etc.

- "Legacy": relationship attaching two classes, a first inherits a second and allowing the first to enrich the definition of the second while retaining all the features of this second class.

- "Interface" in a computer application, an interface is a set of exchange points that allow the application to communicate with the outside world (for example, other applications or users) and to submit services and information.

- "LHM" means Human Machine Interface, and is synonymous with user interface.

- "User interface" in a computer application, the user interface is a special interface: the part of an application specifically dedicated to the two-way communication between the application and its users. Thus, through Ithm, the application presents the data and information processed, for example by displaying graphically on the screen, and the user enters data and triggers actions, eg through form fields, buttons and menus with the keyboard and mouse. These consist of LHM components graphically mimic the appearance of real world objects that identify the corresponding functions displayed. For example, data is often displayed and edited in a rectangle drawn on the screen, mimicking the paper form fields, and the shares are represented by a text in a raised rectangular box sinking when clicked, to like the buttons of electrical appliances. The HMI consists of a static and a dynamic part. The static part includes all the graphics aspects that are shaping and presentation of information.

The dynamic part in turn includes all enabling the user to control the application and interact with it, such as events from devices and management of navigation.

- "Interpretation": Translation of Action a description expressed in a programming language to the native language of a computer for execution by the computer.

- "Programming language": formalism to describe actions to be executed by a computer. These descriptions are to be executed by the computer when the computer's native formalism is used, or after compilation or interpretation. A computer application is described using one or more programming languages.

- "Modeling" means the act of producing a description of an object to achieve, to be a model for its effective implementation. This modeling work is often computer, to abstract certain considerations specific to completion, such as technology used, technical considerations and the programming languages ​​used. This simplifies the design work by reducing the number of concepts to handle. - "Abstract modeling" is the act of representing computer applications to perform in an independent formalism technologies and technical considerations based on abstract concepts.

- "Software development tool": computer application to build computer applications. -^""Technology" software component that can be a component of a computer application made or an intermediate element of its realization process such as a tool or programming language. under this term are grouped among others both programming languages, software development workshops associated with it, the software components that can be assembled into an application, services and technical resources made available by a hardware environment or software and communication protocols between software components.

- "Code generation" means automatic production code for a computer application using a generator. It is done from a software application description provided to the generator and used to control this generation. The latter, after analysis of this description, built the code expected output. This description may be expressed ed in a higher level language than that in which the code will be produced. So often we make choosing a language the closest possible to the natural human expression is graphically or in text form. Thus the generator can operate without having to know the formalism of the programming language used in the generated code.

- "Language": all representations of formats to describe all or part of software to directly or indirectly contribute to their actual construction.

PRIOR ART Currently, tools that generate code does offer this possibility for only one programming language at a time or a set of language structure and the predefined, fixed roles. This limitation is that the code generator is explicitly linked in its structure to the language or to this set of languages. Thus, when one wishes to automatically generate code for any technical architecture comprising multiple programming languages, it is generally required to provide more input descriptions of several code generators. That is to manually code the distribution of the technologies of the technical architecture. This occurs when the application technique to achieve rarchitecture includes several technologies. And today is the most frequent case in the development of a computer application.

To perform code generation, existing code generators are based on higher-level descriptions of the level code to produce. They are often based on modeling languages ​​such as UML and said generators are used to generate code in a given programming language. For example, the Rational tool Rational Rose® company is one of the tools to achieve an abstract model of a computer application using UML.

Regarding languages, can be categorized on a two-dimensional graph as shown in Figure 1. The first, the vertical scale represents the technological independence nature of language. It grows as the information described using the language needed less and less, because of their shape, using a particular technique or functional platform. The second, the horizontal scale represents the facility there to automatically identify the role, structure and operation of an application from its description in a language, that is to say, the ease automatic semantic analysis of the application from its description. Still says otherwise, it is easy to convert this description in a human readable form by the man, saying the operation and the meaning of this application. This scale increases as that both languages ​​- offer notions of growing rich with which one can describe a technical or functional area given increasingly rich by using a number of these ideas ever weaker,

- Require the programmer using increasingly exclusive of these concepts to achieve this description. We can distinguish the following types of languages: the first generation languages: machine languages ​​(eg x86 binary code 68000);

- The 2nd generation languages: symbolic languages ​​(eg assembler x86 or 68000); - The third generation languages: procedural languages ​​and language objects (eg Basic or Java); the 4th generation languages: languages ​​manipulating aggregate concepts and typically supported by software engineering workshops dedicated (eg:

PowerBuilder or Windev); - The abstract modeling languages ​​(eg UML or Merise);

- Description languages ​​(eg HTML, WML).

First generation languages ​​are the lowest-level languages. The instructions that compose them are directly understood by a processor. They are elementary and fewer. In practice, they consist of numbers (expressed in binary) codifying feasible actions by the processor internally or in interaction with their physical environment. These languages ​​are closely related to the physical environment able to execute them. This technological dependency puts the very bottom of technological dependence scale. As regards the automatic semantic analysis, it is virtually impossible because of the elemental nature of the available instructions. Indeed, any transaction in which a human could give a sense of unity may require hundreds of instructions expressed in machine language. This justifies the placement of these languages ​​at the bottom of the scale of ease of semantic analysis. Second generation languages ​​appeared to allow programmers not to directly use the binary codes of machine languages. In place of these codes, programmers could use more understandable symbols directly by man. Nevertheless, these symbolic languages ​​remain as low level languages ​​that first-generation languages, and only the designation of the elementary operations of the language changes shape (from binary to an alphanumeric description). Indeed, their formalism is in direct one correspondence with the binary codes of the first generation languages. They are therefore, like the latter, placed at the bottom of the ladder of technological independence. Regarding the automatic semantic analysis, it is virtually impossible without having a scanner with an intelligence at least equal to that of the programmer having realized the description of this application in this language. Indeed, the formalism is so low that the only items that may carry information of functional or technical meaning could be included in the comments. Or formalism offers no structured functional or technical framework, which prohibits the use for any deterministic analysis. Third generation languages ​​appeared to allow to describe a software application irrespective of hardware that will operate this description to run the application in question and to provide access to more complex base of operations as those of the first and second generation languages. Nevertheless, even if the formalism and syntax are abstract hardware, the possibilities offered by these description languages ​​are closely related to the technical environment that will be used to run the description given. These languages ​​are therefore a first progress of technological independence that allows the programmer to ignore the way the basic functions provided by the language are implemented on the target technical platform, but that does not relieve the programmer of duty arranging these basic functions in a way to take into account the specificities of this platform. Regarding the ease of automatic semantic analysis, the third generation languages ​​also represent progress as they offer a structured framework for certain technical or functional departments including the structure of algorithmic routines and structure manipulated data. However, they often offer the opportunity to remove or circumvent the framework they provide to describe a particular service. However, this level of analysis may not exceed the level of complexity of the basic functions provided by the language, and it is degraded by the possibility of circumvention. Thus, to form units of meaning to interpret the operation of the described application, it needs the intervention of a human or an analysis tool based on artificial intelligence that goes beyond what we can do today.

The fourth generation language (4GL) are coupled with tools commonly called GLA (Software Engineering Workshop). This marriage is so strong we are accustomed to employ either one or the other of the two or 4GL AGL terms. They are born of a desire to capitalization for the establishment of technical components. These AGL, assuming that most applications can be built by assembling and setting generic components, offer a wide range of predefined components that need to set up and to communicate. AGL these are all related to a specific technical language, such as third generation languages, offers opportunities limited by the technological environment of execution which they depend. This limit these 4GL up to the same level of technological independence as the third generation languages. By against, as regards ease of automatic semantic analysis, it is superior to all those mentioned above. Indeed, AGL strictly require the programmer to describe the structure of a technical or functional service. Automatic semantic analysis can therefore rest on a perfect determinism to detect these services, with the limit that the identified service is associated with a specific embodiment with a single technical platform, and is not a generic service. This analysis therefore can not always assume the functional intent of the programmer, but it can always identify technical intention.

abstract modeling languages ​​are born of envy description of applications independent of any technological character. They focused on algorithmic aspects of the data structure. They are used to develop applications in two phases: the first concerns the creation of a model and the second automatic code generation in language (mostly third generation language). This ability to create an independent model of technology for most services to describe a computer application that we place above the other languages ​​we have mentioned so far on the level of technological independence. However, to generate a complete application, it is essential when using these tools to include in the model links with the basic elements of the third generation language that will ultimately be used, making the model in fine dependent on this technology. Finally, it is necessary to describe the computer application that models a particular way depending on the configuration of rarchitecture technique, which makes the model dependent thereof. Regarding the ease of automatic semantic analysis, it is equivalent to that obtained by the use of a third-generation language because the abstract modeling languages ​​provide a structured framework to describe certain functional services. Automatic semantic analysis models and remains, due to the manipulation of concepts of low-level and very abstract (class, relationship, method, cooperation, ...), unable to automatically identify complex services technical or functional individuals, without human intervention or artificial intelligence module without exceeding the current state of the art.

Description languages ​​are based on defining a syntax so rigid IT elements that can be described using. As fourth generation languages, they define higher level concepts that are to be assembled together to form a description. The subject of this description is often graphic and is particularly used in computing to describe a man-machine interface. Historically, they were used to format the text before printing or screen display. The elements that can describe are static. To introduce dynamism, these languages ​​are sometimes associated with a third generation language. They are not intended to allow the generation of an application. Their management is based on tools called browsers, which interpret them to perform what is called rendering their description, that is to say, the transformation of the information in the description language and this provides the latest from its specification. On technological independence, they allow within the capacity of language to display their description of any hardware and software platform, but they require special technical architecture, based on the existence of a tool made. By cons, regarding the ease of automatic semantic analysis, it is at the 4GL, since it is based, like them on a binding structure of predefined services, but requiring specific technical implementation.

DISCLOSURE OF INVENTION

The invention aims to facilitate the development of computer applications and to allow this development occurs more rapidly in comparison to the prior art. It also aims to make it more reliable for both the computer application developed and the course of development of the computer application. It also aims to facilitate reuse of developments for a computer application, for example for the development of another application or to adapt the computer application to a new technical architecture.

To this end, the present invention provides a generation software computer code of at least part of a computer application, in which the software generates said computer code from a description of that part of the computer application distributing said description between several code generators according to modifiable distribution rules, each code generator reflecting part of said description supplied thereto, to provide at least part of said computer code in a respective language. Thus, the distribution rules can advantageously correspond to the technical architecture that will implement the computer application. Of course, it is perfectly possible to address one part of the description to several different code generators, for example if it is desired simultaneously generate the computer code of the computer application for several different technical architectures. The dependent claims define preferred embodiments of the software according to the invention. In another aspect, the invention also provides a software description language, including the type of language object computer application modeling, organized into classes for defining first class providing access to technical and substantive servicing by hardware and software computing platforms receiving computer application, wherein said services can not be defined by that language and other classes can not access any of the technical or functional services via said first classes .

In yet another aspect, the invention provides a software to build graphically or textually a computer application model, including a man-machine interface design of computer application and provide a model description in the language of description software according to the invention.

Other characteristics and advantages of the invention will appear on reading the following description of a preferred embodiment of the invention, given by way of example and with reference to the accompanying drawing.

BRIEF DESCRIPTION OF DRAWINGS

1 schematically illustrates the position of the language according to the invention over the prior art in terms of richness of description and ease of automatic semantic analysis on the one hand, and in terms of technological independence.

Figure 2 shows a generic example of technical architecture. Figure 3 shows an example of actual technical architecture fragment can be used to build an application HTML / JSP intranet.

FIG 4 is a diagram illustrating the operation of an architectural code generator according to the invention.

WAYS OF CARRYING OUT THE INVENTION PREFERRED

We first describe the preferred way to achieve code generation software according to the invention before describing the software description language. 1) The code generation software

For convenience, we will refer later code generation software according to the invention by architectural code generator. Indeed, we will talk later in architectural code generation, as this is to generate code for a technical architecture as a whole, that is to say, to distribute the product code on multiple technologies through generators code each responsible for an architectural technology.

Architectural code generation is performed by the architectural code generator which allows to automatically analyze a description of computer application and then automatically distribute its components, in order to generate the code, according to the description of a technical architecture that defines the choices to be made for the distribution of various code generators and interface adapters between technologies, each supporting a particular technology.

The architectural code generator comprises the following modules: - an application description analyzer able to analyze software application description files expressed in an application description format,

- An architecture description analyzer able to analyze files of technical architecture description in an architecture description format,

- A technological space filter - code generators,

- Server adapters,

- Client adapters,

- A comparator

- A distributor - a coordinator.

We will successively describe each of these elements and the operation of the architectural code generator.

1.1^") Application Description Format This format is chosen to allow to describe the components of the computer application of which is to produce code with the architectural code generator.

It can advantageously be the software description language according to the invention more particularly described in item 2). However, other formats can be used.

1.2) application description analyzer

The application description analyzer is provided to process description files of software applications expressed in the format defined in Section 1.1). It checks the files that transmits conform to that format and, if not, it throws an error. It identifies, without loss of information necessary for the implementation of the application, the factors listed below, from these files then extracts. These elements then constitute a decomposed representation of the application description to be transmitted to other modules. If the application requires the description format, it can be appealed to external files such as libraries to complete this analysis. A description of application done in Java, for example, uses language classes whose definition is not part of the application description but is in external libraries. These libraries are then used in the application description analyzer to identify as the class that is being analyzed is a class of language. The items in question are:

- A list of classes each containing, where appropriate, the list of typed attributes and the list of its methods and their signature typed completely defined and, if applicable, their definition as the sequence of commands and operations that it runs. Can optionally add links to other classes whose class inherits considered if this notion of inheritance is introduced.

- The list of dependencies between classes, put in relation with precisely the point of each class where these addictions have their roots and their target. Each dependency is a dependency between two classes. In this dependence, it is considered that the class that is dependent on the other is the client class. The class is the client class is dependent on the server class.

The decomposition of the description of the application results of the extraction of these elements is expressed in an internal format architectural code generator. This format is shared by all modules that need.

1.3) Architecture Description Format

This format is intended to describe the technical architecture on which will be allocated the product code. This format allows to define:

- Technological spaces: these sets, each with a username, consisting of the combination of: - the reference to a code generator (by its unique identifier), this generator supporting a given technology produce the application code for this technological space,

- An operating parameter set, that is to say, a list of values ​​used to set the operation of the code generator (as defined in section 1.6)

- And a set of filter parameters, that is to say a list of values ​​for the technological spaces filter (defined in 1.5) to allow the latter to check if a class (as defined in Section 1.2) is supposed to be or not supported (within the meaning of 1.10) by this technological space.

- Its associations between adapters and oriented dependencies between technological spaces: for every oriented control of a technological space to another technological space, assigning a server and a client adapter adapter. Dependence is oriented in the sense defined by roles in this dependence from the space that is dependent to the space which it depends. In this orientation, it is considered that the space is dependent on the customer area and the space on which it depends is the server space. The diagram of Figure 2 illustrates a generic example of technical architecture. The diagram above shows 3 technological spaces (El) (E2) and (E3) in which:

- Space (El) is supported by the code generator (GI) and is equipped with the unique identifier (ID-E1), the set of operating parameters (Fon-Ela) and (Fon-Elb) and the filtering parameter set (Fil-Ela) (Fil-Elb) and (Fil-Elc). The space (E2) is supported by the code generator (G2) and features the unique identifier (ID-E2), the set of operating parameters (Fon-E2a) and filtering data set (Fil-E2a) and (Fil-E2b). The space (E3) is supported by the code generator (GI) and is equipped with the unique identifier (ID-E3), the game's settings (Fon-E3a) and (Fon-E3b) and filtering parameter set (Fil-E3a) (Fil-E2b) (Fil-E2c) and (Wire E2D). - Any dependence of a supported application element (E2) to an application member Supported by (El) is supported by the client adapter (Acl) and the server adapter (Asl) . Any dependence of a supported application element (El) to an application member Supported by (E2) is supported by the client adapter (Ac2) and the server adapter (As2) . Any dependence on an application element supported by (E2) to an application member Supported by (E3) is supported by the client adapter (Ac3) and the server adapter (As3) . Figure 3 shows an example of actual technical architecture fragment can be used to build an application HTML / JSP intranet.

1.4) architecture description analyzer

The architecture description analyzer handles files of technical architecture description expressed in the format defined in 1.3.

It checks the files that transmits conform to this format, and if he makes a mistake.

It identifies, without loss of information necessary for the implementation of the application, the factors listed below, from these files then extracts. These elements then form a decomposed representation of the architecture description to be transmitted to other modules. The items in question are:

- The list of technological spaces (unique identifier code generator and game settings). - The list of separated couples customer and server technology, and their client adapter pairs and associated server. The decomposition of the description of the architecture resulting from the extraction of these elements is expressed in an internal format architectural code generator. This format is shared by all modules that need. The architecture description analyzer verifies that the architecture described is consistent with the capabilities of the various code generators and adapters clients and servers that are mentioned are:

- Verify that the filter parameter set of each technological space is compatible with the game of filter parameters associated code generators, relying for this check on the services provided by the technological spaces filter (as described in section 1.5);

- Verify that the client adapters and server mentioned are compatible with the technology supported by the technological area code generator which they are themselves associated; - It also checks that the client and server adapters are compatible with each other;

- It may also be checked, if the code generators are adjustable, that the set of operating parameters of each technological space architecture corresponds to the referenced code parameters in question generator.

JJ also verifies that for a couple of two customer given technological spaces and server, there is only one pair of client adapters and associated server in the architecture description. These checks are done to avoid ambiguities distribution dependencies between classes on the adapters.

1.5) Filter technological spaces This module uses a filtering parameter set as the definition of a set of classes. For a given set of filter parameters, it determines, for each class, if it belongs or not to the entire class defined by the filter parameters set. Finally, it provides two services based on filtering data sets: -the filtering technology areas; - Verification of the inclusion of two filter parameter sets.

Filtering technology areas is, from a list of technological space and a class to return the list of technological spaces for which the class in question belongs to the set of class defined by the set of filter parameters associated with these technological spaces.

The concept of inclusion of two sets of parameters is defined as being two sets of filtering parameters Jl and J2, Jl is included in J2, if for any class C belonging to the set defined by Jl, belongs to C the set defined by J2.

1.6) Code Generators

Code generators are modules of the architectural code generator able to produce code for a particular technology for describing algorithms. Their role is to generate the code for a class from the definition of the latter, its dependencies with other classes. In the case of external dependencies of a class with other classes supported in the same technological space, the code corresponding to the interfaces of this class with these other classes is generated by the same code generators. In the case of external dependencies of this class with other classes supported in different technological areas, the code of this class interfaces with these other classes is not generated, but the code generators are included in the code this class brand they choose, said locating mark, allowing to find the precise location of the code where this dependency will be treated.

If the technology they support requires, code generators produce the necessary files to contain the product code. In all cases, they return the access credentials to access the product code.

Code generators are provided with a unique ID that allows you to designate absolutely in the description of the technical architecture.

They are intended to provide a filtering parameter set defines the set of classes (as defined in section 1.5) they can produce the code.

They also optionally present a list of parameters and how to set the value of these parameters to qualify the hardware and software environment in which this technology is executed and thus more finely define if necessary technological space and conditions of the code generation. An operating parameter may for example be the directory where will be stored files generated source. Another example may be the choice of the version of the 'jdk' for use in the case of using a Java code generator.

1.7) Adapters Server Adapters servers can generate code in one or several given technological spaces. This code can be integrated into the code generated by a code generator. This code plays the role of server interface providing communication between two classes involved in addiction. This code includes the code that produced a generator code for the server class involved in this addiction. The code produced by this server adapter will enable code generated by a client adapter, built-in code that produced a code generator for the client class of this dependency, to interface with it. The server adapters are provided with a unique identifier for designating them in the description of the technical architecture.

They indicate which category of interfaces they rank. These types of interfaces used to determine the compatibility of these server adapters with client adapters. They are freely defined by the servers and adapters can be shared by multiple adapters different servers.

Among the interface categories that can set the adapters include for example CORBA® and RMI ®.

The server adapters indicate what the code generators or they are able to change the product code to insert the code of their servers or interfaces to produce external interface code to the code produced by this or these code generators.

The server adapters produce the interface code from a server dependency of the classes involved in this dependency and access to references to the product code for these classes by the corresponding code generators that dependence.

The adapters servers receive preferably a signal transmission end code generation request, telling them that they will receive over others later in the architectural code generation process. Indeed, some technologies may require adapters expect to have received all the requests before starting to modify the code produced by the generators. It may for example that produced the guidelines must be arranged in a different order than this one in which they were in the original application description and that this order depends on the nature of all relevant instructions.

The server adapters are designed to be able to successively receive multiple server interface code generation requests for several outbuildings, and they choose, according to the constraints of the technologies they are communicating and how they do communicate, they produce and insert the code generated interfaces as of receipt of such requests or if it must wait for the signal transmission end requests issued by the dispatcher to insert this code.

1.8) client adapters adapters allow customers to generate code in one or several given technological spaces. This code can be integrated into the code generated by a code generator.

This code plays the role of client interface providing communication between two classes involved in addiction. This code is preferably integrated with a product code that has generator for the client class involved in this addiction. The code produced by this client adapter interfaces with the code produced by a server adapter, built-in code that produced a code generator for the server class of this dependency.

The client adapters are provided with a unique identifier for designating them in the description of the technical architecture.

They indicate which category of interfaces they rank. These types of interfaces used to determine the compatibility of these adapters customers with server adapters. They are freely defined by the client adapters and can be shared by multiple adapters different customers. Client adapters indicate what the code generators or they are able to change the product code to insert the code of their client interfaces or produce the external interface code to the code produced by this or these code generators.

Client adapters must produce the client interface code from a dependence of the classes involved in this dependency and access to references to the product code for these classes by the corresponding code generators that dependence. Client adapters must understand and use location marks left by the code generators with whom they are compatible.

Client adapters must be able to receive a signal transmission end code generation request, telling them that they will receive over others later in the architectural code generation process. Indeed, some technologies may require adapters expect to have received all the requests before starting to modify the code produced by the generators.

Client adapters must be able to successively receive multiple client interface code generation requests for several outbuildings, and they choose, according to the constraints of the technologies they are communicating and how they do communicate, it must produce and insert the code generated interfaces as of receipt of such requests or if it must wait for the signal transmission end requests issued by the dispatcher to insert this code.

In the end code generation, adapters must have taken away the code the location of brands that code generators have placed there.

1.9) Comparison

The comparator checks the consistency between the code generation capabilities offered by the description of architecture and the needs of the application description in terms of code generation. So it verifies that all classes and dependencies between the application classes are supported by technological spaces and appropriate adapters. To do this, the comparator particularly uses the services of technological spaces filter. It verifies the following conditions: - For each of the classes that the application description analyzer detected in the application description, it checks that there is, in the description of the technical architecture, a technology space supporting these classes;

- For each dependency defined in the application described, between a client and a server class absorptions class by different technological spaces, it checks that there is a server adapter and a client adapter associated with each pair consisting of a technological space that supports the client class and a technological space that supports server class.

If gaps in the description of the technical architecture to the needs of the application that results in an inability to generate the code, the comparator outputs an error message by communicating these gaps.

1.10) Splitter

The dispatcher is responsible for distributing the classes and dependencies of the decomposed representation of the description of the application, depending on the architecture, the different codes generators and client adapters and server adapters, as required by the process described in 1.12).

If the order in different client adapters is not indifferent to the code generation, it determines this order and then calls the client adapters involved in that order. If the call to order different server adapters is not indifferent to the code generation, it determines this order and then calls the server adapters involved in that order. If the order in different generators is not indifferent to the code generation, it determines this order and then calls the generator concerned in that order.

1.11) Coordinator

The coordinator connects the calls of the various elements of the architectural code generator described above. It follows the process described in section 1.12) and ensures the transmission parameters needed to operate the architectural code generator from one module to another. Finally, it ensures the interaction between the architectural code generator and the external system (calling program or human user) that triggers the operation, sending him into errors and any messages sent by the various modules.

1.12) Operation

We will describe how the architectural code generator in connection with Figure 4 illustrates the steps of the operation. Step Init. The external system triggers the generation of architectural code via the coordinator. It transmits the list of the application description file format described in paragraph 1.1) and files in architecture description format described in section 1.3). If there is provided multiple files, there is provided simultaneously in the case where their presence at all is required to interpret the description.

Step 1. The coordinator provides the application description analyzer the application description files expressed in paragraph 1.1 of the format). application description analyzer analyzes these files and returns the decomposed representation of the application. On failure emitted during this step, the generation process stops. Step 2. The coordinator provides the analyzer description of the architecture architecture description files expressed in paragraph 1.3 of the format). The architecture description analyzer analyzes these files and returns the decomposed representation of architecture. During this stage the architecture description analyzer performs the following tasks: Step .. 2.1. If the code generators are configurable, the architecture description analyzer requesting the code of each technological space generator to get its list of operating parameters.

The architecture description analyzer then verifies that the set of operating parameters of these technological spaces defines value as the parameters of this list. In any case, it seeks the code generator of each technological space to obtain its filter parameter set.

Step 2.2. For each technological space, the architecture description analyzer questions the technological spaces filter and invokes the audit department of the inclusion of two filter parameter sets, to verify that the game of filtering parameters of technological space is included in the filter settings set the generator. An error is thrown otherwise.

Step 2.3. For each server adapter used in architecture, architecture description analyzer questions this adapter in order to refer the list of code generators with which it is compatible, and the category in which it classifies interfaces that it generates. The architecture description analyzer then verifies that each technological space the server adapter must perform the server interfaces, code generator associated with this space is present in the list of code generators with which it is compatible. An error is thrown otherwise.

Step 2.4. Each client adapter used in architecture, architecture description analyzer questions this adapter in order to refer the list of code generators with which it is compatible and the category in which it classifies the interfaces it generates. The architecture description analyzer then verifies that each technological space the client adapter must perform the client interfaces, the code generator associated with this space is present in the list of code generators with which it is compatible. It also checks that the client adapter in question produces many interfaces of the same class as the server adapter to which it is associated. An error is thrown otherwise. On error, the build process stops.

Step 3. The coordinator transmits the decomposed representation of the application and the decomposed representation of architecture in comparison. The comparator checks that the requirements of the application in terms of code generation are supported by the architecture: Step 3.1. For each class defined in the application, the comparator questions the technological spaces filter and relies on filtering technology service spaces, to obtain the list of technological spaces of architecture that support this class. The comparator then checks for each class, this list is not empty. Otherwise, an error is issued. The comparator then continues the detection of gaps by ensuring that for each dependency between two classes, architecture defines a client adapters and server pair for each pair of space technology that supports both classes of this dependence.

If the comparison results in an error, the list of deficiencies detected is transmitted to the caller and the build process stops.

Step 4. The coordinator sends to the dispatcher the split up representation of the application, the decomposed representation of architecture. During this step, the dispatcher performs the following tasks:

Step 4.1. For each class defined in the application, the dispatcher asks the technological spaces filter and relies on filtering technology service spaces, to obtain the list of technological spaces of architecture that support this class.

Step 4.2. Each class and each technological space that supports this class, the dispatcher includes this class, its dependencies, indicating those that correspond to it in dependence on classes supported by different technological spaces of the space, and transmits to the associated code generator in this space. The dispatcher also transmits the operation data sets describing the hardware and software environment defined by this technological space. In return, the dispatcher obtains the access references to products source code.

Step 4.3. The dispatcher handles each dependency of the split up representation of the application description regarding two classes supported by various technological areas.

For each of these dependencies, the dispatcher then determines which server adapters must support this addiction, according to the architecture description. For a dependency between a client class and a server class, the server adapters in question are those that are associated with a dependency between the technological spaces that have taken charge of the server class and the technological spaces that have taken charge of the customer class. For each of these dependencies, the dispatcher then sends this dependency, and the classes affected by this addiction and access to source code references associated with these classes, these server adapters. Step 4.4. The dispatcher handles each dependency of the split up representation of the application description regarding two classes supported by various technological areas.

For each of these dependencies, the dispatcher then determines which client adapters must support this addiction, according to the architecture description. For a dependency between a client class and a server class, client adapters in question are those that are associated with a dependency between the technological spaces that have taken charge of the server class and the technological spaces that have taken charge of the customer class. For each of these dependencies, the dispatcher then sends this dependency, and the classes affected by this addiction and access to source code references associated with these classes, these client adapters. Step 4.5. The dispatcher calls each server adapter that was requested in step 4.3 and sends the request to end signal transmission. This call is made in the order required if necessary, as determined by the dispatcher.

Step 4.6. The dispatcher calls each client adapter that was requested in step 4.4 and sends the request to end signal transmission. This call is made in the order required if necessary, as determined by the dispatcher. On error, the build process stops.

2) The software description language 2.1) Language Qualification of the invention.

The invention includes a software description language. It allows him to describe software, existing or under development, without this description does not contain information related to the practical and technological realization of this software (that is to say, without dependence on specific capabilities a programming language, a computer hardware or software platform, or more generally of a particular technology) but by describing in concrete terms its operation. The concrete description of the operation is achieved through the provision via the language of practical concepts related to the practical work of computer applications. These concepts are intended to be the basis for the description of the application. Exploiting these concepts and clarification of their operation and their role can be based on their association with functional and technical specification expressed in a language, which can even be a natural language such as French, which presumably by technologies used to implement it. One example is of such notions as graphic component, device event, data verification from an input in man-machine interface, navigation, information storage, search query to information in an information storage structure, etc.

The absence in the descriptions using one language with the invention, information related to the practical and technical implementation of the application described up this language, in the ranking pattern languages ​​of Figure 1, above the abstract modeling languages. Indeed, the level of technological independence is higher as it does not suffer from their limitations described in the section dedicated to the art.

As regards the horizontal scale of the diagram of Figure 1, the language according to the invention is located to the right of fourth generation languages. Indeed, if, like them, the automatic semantic analysis can be based on the assurance of the use by the programmer, a strict framework for modeling a given technical or functional area, the wealth elements available to describe a computer application is superior because it is made independent of a specific implementation and focuses on the description of the service.

2.2) Language Structure 2.2.1 according to invention) Background

The invention is based on a software description language, that is to say, it enables a representation of all or part of a software application. Language considered to define classes called standard classes.

This language can define elementary operations for describing algorithms. This language supports possibly the legacy, that is to say the ability to define other classes enriching classes. If support legacy plug, possibly the language used to define abstract classes, that is to say, classes that can not instantiate objects and some methods can be abstract, that is ie methods whose operation is not defined but should be defined by non-abstract classes that inherit from these abstract classes. The language may be used to define the scope of the attributes, methods and classes, that is to say the ability to access other classes in these different elements according to their relative position. This language supports polymorphism possibly, that is to say the ability to manipulate an instance of a class B inheriting a class A as if it were an instance of class A and during method calls this body handled as an instance of a class a, using the implementation defined in class B instead of implementation defined in class A. the vocabulary and syntax of the language are indifferent, the time that they respect the limits established in the preceding paragraph. This language can possibly define primitive types (eg, boolean or integer) that are not necessarily of the classes, and in this case, possibly define elementary operations for manipulating these primitive types.

The language is defined by a specification that specifies all of these elements and their conditions of use (vocabulary and syntax, and if so, inheritance, polymorphism, abstract classes, scope, primitive types, elementary operations).

Finally, the language, as defined previously, does not provide and does not provide means of access to technical and functional services that can be provided by any hardware and software platform capable of hosting a software modeled using this language, apart from the above-mentioned elementary operations. As an example of those services to which the language should not provide access at this stage include: the ability to display information on a display or printer device, receiving an order issued by peripheral events like keyboard or mouse, communication with an information storage service, ...

2.2.2) The invention

The invention consists of:

- Enriching vocabulary and syntax in order to provide the specific description format for language classes so-called core classes,

- And optionally associated with this language technical definition of these fundamental classes.

These classes are called fundamental, because they give to other classes that use them, access to basic technical and functional services, that is to say services that are not worn by these fundamental classes via a definition expressed through language itself. Unlike standard classes, the link between the basic classes and their definition is external to language. It totally depends on an outdoor interpretation, for example by tools using this invention, based on an external definition for basic classes. The description format of fundamental classes, integrated with language, allows:

1 can always identify a fundamental class as such,

2- always able to distinguish a fundamental class of a standard class,

3- define its unique identifier,

4- to define its attributes, which can not have a scope making them invisible to any other class if the language provides for the definition of the scope,

5- to define said basic methods without in detail the operation, which are non-abstract nature, in the case where the abstract classes are supported, and which can have a range making them invisible to any other class if the language provides the scoping. These basic methods are methods whose definition is limited to only signatures but whose operation is not expressed through language itself and must nevertheless be regarded as defined by any system operator that language.

The technical definition of the fundamental classes needed for a fundamental class, provide:

1- description through language as enriched by the above description of the basic classes of format

2- if the inheritance is supported and in which case optionally, a lexicon and syntax compatible with the language specific to this class, defining the format used in the language to describe the classes inheriting from this class,

3- if the invention provides the comprehensive functional or technical specification of the services of this class, expressed in a language independent of implementation technology, which can even be a natural language such as French. This specification should not assume the technologies used to implement it. It should clarify the operation of all the fundamental methods of this class (see the last bullet point above devoted to the fundamental classes description format). This is a summary of the full semantics of points 1 and 2 of this technique. This specification will eventually be translated into the languages ​​of the people likely to produce tools that support this class, with, for each version, the reference language for this based on a language identification system defined.

The operation of these fundamental classes is not explicitly defined algorithmically, using the language itself, but can be set only by functional specification or technical expressed in a language independent of implementation technology, such as a natural language like French for example.

In addition, due to the absence exposed in 2.2.1) means of access to technical and functional services that can be provided by any hardware platform or; software, only the core classes are likely to give access to these services.

The core classes are themselves subject to the laws of inheritance if it is present in the language. In this case, one can inherit a fundamental class of a standard or basic class, just as you can do inherit a standard class of a standard or fundamental class.

2.3) Operation

Operation fundamental classes. The implementation of the fundamental classes specification is entirely devoted to tools that use a language of the invention. These are the tools which perform or simulate the operation of those classes, according to the needs.

Responsibility for the operation of the fundamental classes. Tools that use or can perform an application description with a language according to the invention and depending on the fundamental classes, and must be designed to take into account the specifications of these fundamental classes when they have to interpret. The interpretation of the role of these fundamental classes by these tools is therefore based on the compliance of these tools with the specifications of these fundamental classes.

possible integration of core classes in a language. Language according to the invention may optionally include in its specification itself, a set of these fundamental classes (in this case non-editable language user) which, when specified as described in point 2.2.2 Technical , allow software descriptions made through this language and exploiting these fundamental classes to base these programs on the services of these fundamental classes.

Extension of a language by the fundamental classes in use. The technical definition of the fundamental classes can also be made available to users of the language to extend the capabilities of the language beyond its specifications by adding new fundamental classes in addition to the basic classes may be provided with language. In this case, it is preferable to provide the tools exploiting the language of an extension mechanism that allows users defining the new basic classes to enhance the functioning of these tools by using additional modules so that these tools can consider as part of their operation these fundamental class as * sρécification of these classes.

Interest in automatic semantic analysis. The tools to analyze the descriptions made by a language with this invention will be able to identify technical or functional services by simply identifying the use of the fundamental classes in the application description. This analysis will be made and unambiguous. Indeed, the ability of an analytical tool to provide automatic semantic analysis of these descriptions is based only on knowledge, the developer of this tool, the fundamental class specifications, not on the deduction of the role of classes used by algorithmic analysis of the definition of the classes described using the language, which is impossible today without human intervention.

Exclusive concept definition and method of reinforcement. As part of a language according to the invention, exclusivity, owned by the fundamental classes, the provision of hardware or software provided service based on the specifics of the software home platform described is ensured by the absence of these groups in the definition of the language itself. By cons, for purely algorithmic services, this exclusivity is not guaranteed by the language, because it allows the description of algorithms, and therefore rely on an external constraint. This exclusivity is the assurance of complete determinism of automatic semantic analysis. For sure, we will develop tools producing software descriptions described by a language with this invention, such that it is impossible to use language to describe algorithms in some cases supported by classes fundamental giving access to particular algorithmic services.

Application code generation. Among the possible applications of automatic semantic analysis permitted by the invention include generating code distributed to technical architectures allowing in particular a program described using a language with this invention to be scope to any technical architecture providing the services described by the fundamental classes used in the description of this software. In particular, a language according to the invention can advantageously be used with a code generation software according to the invention such as the type described in paragraph 1) of the present description.

Of course, the present invention is not limited to the examples and the embodiment described and shown, but is capable of n shady variants accessible to persons skilled in the art.

The code generation software and the software description language according to the invention provide an increase in productivity of the development of estimated IT applications to almost 70% by automating a number of programming tasks. The invention also provides an unmatched freedom compared to the technologies used in the development process. Technology is a major cause of hazards and uncertainties in IT projects. This freedom leads therefore by decreased risk of failure and better keeping budgets and deadlines. Failure to define as an independent application model technology offers several advantages. First, we need not consider the technical constraints during modeling, which simplifies thereof. Then it provides a model closer to user expectations because not perverted by issues that have nothing to do with the functional. Therefore the design phase converges faster towards the desired result. Also, there is not then other tasks to run the realization of this model. Indeed, one can obtain the full implementation achieved technically without human intervention other than essential engineering design. This is possible because we can produce the programming code automatically from the model that contains all the information necessary to describe the application.

Furthermore, the invention improves reliability on two levels: the reliability of the computer application obtained and reliability of project development forecasts. Regarding computer applications, they may be made automatically by the code generation software and they do not have other errors than those introduced in the functional design, and those introduced by the code generators themselves. It is reasonable to assume that these will be fewer than those produced by a human programmer because the programming patterns used can be run on a number of important projects. And they are likely fixes and incremental improvements over the life of the product, which will capitalize on progress in quality. As for the errors introduced by the functional design, the models produced by application of the invention is easier to validate, it is estimated that there will be fewer.

Concerning the progress of projects, it should be noted that in many projects, the technical aspects introduce unsuspected implementation difficulties and some architectural choices prove disastrous to use for meeting deadlines and budgets. Until we were often forced to suffer because it was too late to go on this type of choice. Thanks to the invention, technical constraints are handled by code generators, and architectural choices are revised. The progress of projects therefore suffer more smoothly and will deviate less forecasts. Finally, another element may be even more important who comes regularly disrupt projects, is the change of functional specifications during the project. It is an almost systematic event and has serious implications for the load in terms of projects. This disadvantage can be avoided because there is no impact in terms of load other than redefining the model thanks to the invention, and technical transcription of these changes has a near-zero cost as we have seen . As the functional specifications are validated with users from the model simulation, the changes should moreover be less frequent because a validation in real conditions is more reliable than a validation of schemas or model. Another advantage of the invention is the ability to reuse developments. This outcome possibility of independence of technology, allows to capitalize within a project or between projects with functional elements in common. This significantly reduces development costs and increases the relevance of the applications produced by cross-validation which they are thus subject. In the long term the ability to reuse can result in the possibility of porting the application. This will migrate an application into a new technical architecture, when necessary, without significant additional cost.