FR2887348A1 - Data structure for creating e.g. unified modeling language object model, has set of clauses e.g. manipulatable logic clause, where each clause is entirely declarative and associated to component of object formalism modeling - Google Patents

Abstract

The structure has a set of clauses e.g. manipulatable or upgradeable logic clause by a program. Each clause is associated to a modeling component of an object formalism modeling, and is entirely declarative. The clause comprises a code relative to the modeling component, where the component is a package, case, class, attributes, association and inheritance. Independent claims are also included for the following: (1) a computer programming product adapted to upgrade, access, or to manipulate a data structure (2) a file readable by a computer comprising a data structure (3) a method for processing data.

Description

The present invention relates to a data structure compatible with a

  object modeling formalism, eg UML notation, as well as a data processing method for creating a UML model or generating code.

  In this description, the following terms are used with the meaning indicated, unless otherwise indicated: - computer application: means any program or set of programs intended to function together, the purpose of which is to render services to their users.

  - class: refers to the notion of class commonly manipulated in object-oriented programming modeling and programming languages and in particular the aggregation of data and processes (or attributes and methods, respectively) intended to work together in a computer application. In object-oriented languages, each object type is defined by its class. A class represents the set of objects that share the same attributes, operations, methods, relationships, and semantics.

  - line: an expression or sequence of expressions of a symbolic language providing specific information to a destination program, for example to the compiler.

  - container: in object-oriented programming, an object comprising other objects, such as a dictionary, and which provides the operations to access its contents. It can also be a component comprising other components.

  - source code: text written in a programming or description language which is then compiled in machine language in order to be executed by a hardware computing platform, or interpreted by a software environment or interpretation material.

  - code: indifferently designates source code or compiled code.

  compilation: action of translation of a description expressed in a programming language into the native language of a hardware computer platform, before it is executed by this hardware computer platform.

  - declarative: refers to data collected without the indication or necessity of the order in which they are to be used. When this order is indicated, the representation is no longer declarative but procedural. The two concepts generally overlap, in the sense that a language may include declarative parts and other procedural parts.

  - DTD: (for document type definition or definition of document type), designates a model of logical structure of a document, making it possible to fix the elements to compose the document as well as the nature of the links to link these elements. We also use the English word schema.

  - code generation: here refers to the automatic or semiautomatic production of source code for a computer application, by means of a generator. It is based on an abstract description of a software application supplied to the generator and used to control this generation. This one, after analyzing this description, builds the code expected at the output. This description is usually expressed in a higher level language than the one in which the code will be produced. Thus one often makes the choice of a language as close as possible to the natural human expression, either in graphical form or in textual form. Thus we can operate the generator without having to know the formalism of the programming language used in the generated code.

  - inheritance: a relationship that links two classes in which a base class inherits the properties (attributes and methods) of a parent class, and allows the first class to enrich its own definition with that of the second, while retaining all its original features. An inheritance is enriching (we add to the class that inherits the properties of the inherited class) and not depleting (we can not not inherit all the properties of the parent class).

  - HUTN (for Human-Usable Textual Notation), refers to an Object Management Group (OMG) standard that allows you to create and modify text-based templates with human-readable syntax. This syntax has been designed to be generic, automatable and understandable by the user. HUTN is recognized as being simpler and obviously more readable than XMI as user oriented, it is close to known languages such as Java, C ++.

  Instance means an occurrence, a copy, an individual member of a type or class. A member of a class is commonly referred to by the terms synonymous with object or instance.

  - programming language: formalism to describe actions to be executed by a computer. These descriptions are executed by the computer after compilation or interpretation. A computer application is described using one or more programming languages. By the term language, we mean all formats of representation to describe all or part of the software to contribute directly or indirectly to their effective construction.

  - metalanguage means a language that takes another language as its object and formalizes it.

  - metamodeling refers to the specification of a modeling language by means of another modeling language (metalanguage), a metamodel being a model representing the syntax of a language.- modeling means the abstract representation of a statement, a problem or system, carried out on the one hand for the purpose of understanding and communicating this understanding, and on the other hand for the purpose of solving the problem or of concrete implementation of the system.

  - object-oriented modeling refers to a particular type of modeling in which the modeling elements are classes, objects, attributes, methods, associations, etc. as opposed to "functional modeling" in which the modeling elements are processing functions and data streams. See also UML.

  MOF (for Meta Object Facility) is a metamodeling language proposed by the OMG and used to specify the syntax of UML and other modeling languages.

  - OMG (for Object Management Group), refers to an organization whose purpose is to define standards in order to guarantee compatibility between applications programmed using object-oriented languages (see http: //www.omg .org).

  - object: designates, in modeling or object-oriented programming, a class instance, consisting of a set of data (the class's own defining data) and procedures useful for handling them.

  - object-oriented, for example, a model, a language, an application or application elements whose constituents are classes and objects. For example an object-oriented language is a programming language in which the basic components are classes, whose instances the objects live dynamically in the computer program that uses them.

  - package (of the English Package, the latter being the most commonly used in the art): firstly designates a set of modeling elements (classes or other packages ...) that are grouped together to be reused or better organize a model. Once the model is coded in the programming language, the package designates a directory (a folder) of the computer that contains classes or other packages.

  - object-oriented programming: a particular type of programming in which an object-oriented language (eg Java, C ++, C # or Eiffel) is used that manipulates classes and objects as opposed to "non-object" classical programming in which only simple data structures and separate processing "functions" (eg C, COBOL, FORTRAN).

  - SGML: a standardized language for describing the relationships between the content of a computer document and its structure.

  stereotype (stereotype) means a type of modeling element that extends the semantics of the metamodel. Stereotypes must be based on certain types or classes existing in the metamodel. Stereotypes can extend semantics, but not the structure of preexisting types and classes. Some stereotypes are predefined in the UML language, others can be defined by the user. Stereotypes constitute, with tagged values and annotations, one of the three UML extension mechanisms.

  - UML (Unified Modeling Language): designates an object-based notation (rather than a language) for the purpose of determining and presenting the components of an object system during its development, as well as, if necessary, to generate documentation. UML is currently the OMG standard. It results from the merger of the works of Jim Rumbaugh, Grady Booch and Ivar Jacobson and knows many evolutions.

  - XMI (for XML Model Interchange), allows you to specify mapping rules between metamodel and "schema". XMI is the OMG standard that forms the interface between the world of models and the XML world of the World Wide Web Consortium (W3C). It is used to represent UML models in the form of XML files.

  - XML: an evolution of the SGML language, which allows designers of HTML documents to define their own markers, in order to customize the data structure.

  Modeling is known as object modeling, which consists of creating a representation of real-world elements in terms of classes and objects, independently of any programming language. For example, object classes are determined, their own data and the functions that use them are isolated.

  Various formalisms exist. UML is one of these formalisms (it is actually more of a catalog of notations).

  Object-oriented languages each constitute a specific way of implementing the class concept. In particular, a formalism or an object method makes it possible to define a problem with a high level of abstraction without going into the specificities of a given language. It also offers, via UML, a tool to easily represent a problem in a graphical way, making it more accessible to the various actors involved in its resolution.

  Typically, an abstract design of an object model is first carried out, for example in order to solve a given problem. Then, the model is implemented using an object-oriented language (such as C # or Java).

  It is therefore preferable that an object formalism be defined as rigorously as possible, preferably that it be unique, in order to minimize ambiguities. Among the various ratings that have been developed, UML has emerged in the course of the 1990s, as a standard OMG.

  Tools are also known for performing a grammatical analysis of a text, for example Grammatica, which is a grammatical and orthographic verifier of French and English texts. In addition to suggestions, he provides explanations. Grammatica analyzes the function of words (text and grammatical links, homophones and homographs, synonyms and definition in French). The reader can consult the site www.zdnet.fr. Another example is Lexiquest's tools for text analysis and text mining: www.lexiquest.com.

  There are also known tools for generating code, from a proprietary internal representation, unpublished and not accessible to the user (eg IBM Rational Rose, Objecteering Softeam, Rhapsody i-Logix).

  To perform code generation, existing code generators rely on higher-level descriptions than the level of code to produce. They are often based on models such as UML and these generators allow to generate the code in a given programming language. For example, the Rational Rose tool is one of the tools for performing an abstract modeling of a computer application using UML.

  The UML notation, as it is currently normalized, does not have any textual notation to represent the object models; only a graphical representation is proposed in the standard for the different UML diagrams (diagram of classes, interactions, state-transitions, etc.) but no textual counterpart of this graphical representation is proposed in the UML standard. . XMI was not designed to be readable, that is, it is not understandable by a user. Moreover, he is not self-sufficient. The HUTN syntax has been designed to be understandable by the user. It remains that HUTN is a procedural language, that is to say that the order of the lines is of critical importance for the interpretation of this language.

  In this context, it would be particularly desirable to have a data structure, exploitable computer that can represent UML models and a facilitated generation of source programs in any object language. It would also be desirable that this data structure be simple and light to handle and, once reified, understandable by the user.

  To this end, the invention proposes a data structure compatible with an object modeling formalism, this formalism comprising a plurality of modeling elements, in which: the data structure comprises a plurality of clauses, each of these clauses is associated with one or more formalism modeling elements, and each of these clauses is fully declarative.

  In preferred embodiments, the data structure according to the invention comprises one or more of the following features: each of said clauses relates to a single modeling element; each of said clauses comprises a code relating to the modeling element to which it refers and characteristics relating to this modeling element; some of said clauses include features relating to a container of the modeling element to which it refers; the object modeling formalism is the UML notation; - one of the formalism modeling element is: a package, a use case or user case, a class, an attribute, an association, or an inheritance.

  The invention also relates to a computer program product adapted to enhance, access and / or manipulate the data structure of the invention.

  The invention further relates to a computer readable file comprising a representation of the data structure according to the invention.

  The invention further provides a data processing method comprising: a step of valuing the data structure according to the invention.

  In preferred embodiments, the method according to the invention comprises one or more of the following features: the method comprises, prior to the valuation step, a step of decomposing data into modeling elements of the formalism; and a formalism modeling element is represented as a clause of the data structure, during the data structure valuation step; the data decomposition step comprises a grammatical analysis of a text; the grammar analysis in the decomposition stage comprises each of the following sub-steps: splitting the text into sentences, solving enumerations, for example enumerations introduced by and, or, as well as or either ... or, subordinate resolution , for example subordinates introduced by whom, that, of which, where, to or to the elimination of certain words according to given criteria, at the end of the sub-resolution step of subordinates, resolution of canonical forms of names, resolution of name cardinalities and attribute resolution; The method comprises, after the recovery step: a step of creating an XMI model via an XMI generator from the data structure; the method comprises, after the step of creating the XMI model, a step of producing a UML model from the created XMI model; and the method comprises, after the recovery step: a step of accessing the data structure and a step of generating a code.

  Other features and advantages of the invention will appear on reading the following detailed description of the embodiments of the invention, given by way of example only and with reference to examples, as well as to the appended diagrams, which show: Figure 1: an example representation of a UML model; Figure 2: a diagram schematically showing some steps of a data processing method according to one embodiment of the invention; and FIG. 3: an exemplary representation of a UML model obtained by implementing the data processing method according to one embodiment of the invention, from a reference text.

  The invention proposes a data structure. By data structure, we mean first the actual structure of the data as manipulated in the internal representation of a program that exploits them. However, data structure also means the structure of the information present in a file, as it would appear when editing this file or when it is printed. This file could for example be a reification file of the above data structure, as understood in its first sense.

  This data structure is the internal representation of an object modeling formalism comprising a plurality of modeling elements. By representation of an object modeling notation, it is understood that the exploitation of the data structure notably allows a graphical representation according to this notation formalism. The latter could for example be limited to the UML notation, in which case the modeling elements are the elements conventionally handled by UML, that is to say, packages, classes, attributes, operations, associations, cardinalities, inheritances, etc. The data structure according to the invention comprises a plurality of clauses, for example logical clauses vaforisable or manipulable by a program.

  Each of these clauses is associated with one or more modeling element (s) of the formalism and each of these clauses is entirely declarative.

  This data structure is simple. Once the data structure reified, for example in a file, each clause becomes a line of this file, using a formal notation. However, since each clause is entirely declarative, the order of these clauses and consequently the order of the lines of the file, does not affect their interpretation. The understanding of the file by a user is simplified.

  Preferably, each clause corresponds to a single modeling element, which simplifies both the algorithmic processing of the data structure as well as the user's understanding of a file constructed from this data structure.

  In addition, each clause is preferably self-sufficient, so that it can be interpreted without having to access another clause for that purpose.

  The data structure according to the invention is represented by a formal high-level notation. This allows the implementation of simple and integrated data processing methods. These may be, for example, methods for transcribing and representing UML models, which are usually described in the form of diagrams and graphical diagrams to which non-formal texts are associated and whose structure is not standardized. The data structure according to the invention makes it possible, by appropriate computer processing, to easily produce UML compliant object models, as well as source programs, in any object language (Java, C ++, C #, Ada, etc. .). This will be detailed later in the description.

  This data structure thus advantageously replaces the currently proposed alternatives, which, based on XMI / XML or HUTN, do not offer a tool 30 that is both simple, lightweight and able to easily generate code.

  In what follows, the formal notation mentioned above is denoted by the acronym FIL (for format interchange language or Format Internai modeling Language). In addition, the data structure according to the invention is described with reference to a reification file of this data structure, for reasons of intelligibility. The fact remains that to a line of this file can correspond a logical clause, interpretable by a computer program.

  In one embodiment, each FIL line of the file comprises a code relating to the modeling element to which it relates, if necessary a simple character specifying the type of element described. For example, we could use the character a for an attribute, c for class, h for inheritance, r for relation, and so on. Each line further comprises a body including features relating to that element. This makes it possible to have a structure suitable for use of the line by a computer application. The identification of the element by the user is further facilitated by the presence of the corresponding code.

  Consider for example the following sentence: a cat eats mice. This sentence establishes a relationship between a cat and mice. This relation can be encoded, according to the IDF notation, in the following line: r: cat (1..1) eat (1..n) mouse where the character r specifies that the element of modeling in question is a relation, (1..1) and (1..n) refer to the cardinalities corresponding respectively to (a) cat and (of) mice.

  Other examples will be widely detailed later.

  Preferably, the body of certain IDF lines comprises two parts, the first part comprising intrinsic characteristics to the modeling element (for example a type value for an attribute) and the second part comprising characteristics relating to a container of the modeling element. This declares an element, directly in connection with its container. However, the declaration relates mainly to this modeling element, the container being subject to independent reporting. Thus, the corresponding declarations (ie clauses or file lines) remain independent. In this way, we set up a file structure allowing an application later to rebuild hierarchies between the various elements.

  The following detailed examples come within the scope of a particular embodiment, in which the FIL lines are sorted by type, for reasons of readability, for example in the following indicative order: packages, classes, attributes, operations, associations, inheritances. This makes it easier to understand the elements and their relationships. It should be borne in mind, however, that these lines can be declared or stored in memory in any order.

  Preferably, the codes specifying the elements are reduced to a letter, tiny, in first position on the line. A (two-dot) character is immediately after, followed by a space, as shown in the example above. In addition, a comma (if there is one) is always followed by a space. Other syntax rules can be observed, as will appear in these examples.

  Where appropriate, an operating computer tool, i.e. for producing and / or processing a data structure according to the invention, is used. This tool can be adapted to value the data structure, that is, to assign values corresponding to the data. It can also be adapted to access this structure, that is to say to be able to extract values and / or manipulate the data structure (or replace the values). In particular, this tool is adapted to interpret the FIL lines of a file. If necessary, it may be equipped with routines responsible for correcting or interpreting syntax defects or incomplete syntaxes. Lines can be stored in memory in any order.

Example 1

  The declaration of an attribute is as follows: a: attribute name, class name where attribute name and class name logically refer to the name of the attribute and the class to which the attribute belongs, comma acting as separator.

Example 2

  a: attribute name: type, class name In this example, an attribute is declared with its type. Preferably, there is no space, neither before nor after: type. Standard types are for example String, boolean, int or integer, date, as is customary in the art. Other types may be used, including the class names described in the notation itself.

  For example, we will have: a: attribute name: class one, class two

Example 3

  a: attribute = value, class name Here, an initial value is assigned to the attribute. There is no preference for space, neither before nor after the equal sign. It can be noted that an incomplete syntax (like the example above where the type of the attribute is missing) can advantageously be interpreted by an operating computer tool. For example, the tool in question can be designed to automatically interpret and find the right type, taking into account several criteria. These criteria can for example be based on the name of the attribute itself, such as "number", "amount", "counter", etc., the operating tool then offering by default the type "integer" . They can also be based on the value associated with the attribute. For example, if the value is "true", "false", "true" or "false", the proposed type is "boolean"; if the value is numeric, the proposed type is "integer" or "real" depending on whether it contains decimals or not, if the value is surrounded by double quotes "", the proposed type is "String" (for string), etc. Thus, in many cases, the type may be superfluous because the type can be restored by the tool.

Example 4

  a: attribute: type = value, class name In this example, the syntax is complete.

Example 5

  c: class name [, package name] Here, a class is declared, as well as [, its membership package]. The square brackets indicate here the optional character of the name of the package. For example, if the package is not mentioned and if there is no previously encountered package, the class can be stored systematically in a given package, for example the package "p_system", which will then be considered as the highest level package.

  For example, this package may exist by default and can only be used if a class does not have a recipient package. In this case, if the package name is not mentioned, the class can be stored in the last package p: encountered in the FIL file, by the operating computer tool. Note that the notion of order intervenes here only to compensate for a syntax defect on the part of the user. Similarly, the explicit declaration of a class with c: can be omitted, by adapting the exploitation computer tool so that the classes are recognized and declared automatically from attributes, operations, associations and legacies. However, the c: code is used by the operating computer tool for the output FIL file. On the other hand, one can advantageously use the code c: to declare a class with stereotype (see below) or to force the membership of a class to a package.

Example 6

  c: <<stereotype>> class name [, package name] Here, a class is declared with a stereotype [, and its membership package]. If necessary, a stereotype can also be associated with packages, attributes, operations and associations.

Example 7

  h: class name 1 is a class name 2 In this new example, an inheritance is declared, using a keyword. The keyword used, necessary for the declaration of the inheritance, is is-a. It should be noted that the code h: can be omitted. If it is not present, the code can be automatically added by the operating computer tool, which interprets the line FIL as pertaining to an inheritance element, because of the presence of the corresponding keyword. The line can be entered just as in the following example: square is a graphic element.

Example 8

  o: operation name, class name Here, an operation is declared. Only one comma is needed, followed by a space.

Example 9

  p: package name [, enclosing package] Here, a package is declared, as belonging to the enclosing package named enclosing package. The mention of the enclosing package is optional.

Example 10

  r: class name 1 (1..1) association name (1..n) class name 2 This example illustrates a way to specify cardinality. Two numbers are used, at each end of the association and in parentheses. Depending on the case, the instruction starts with (1, (0, (m or (n and ends with 1) or n), there is a space before and after.For the name of the association or the class, this one can be any one, composed for example of one or more words.There is also a space before and after this name.In addition, if the association name is composed-of or contains, an aggregation It can automatically be generated in a UML tool that is used later, and, like the h: code, the r: code is not mandatory, as the operating computer tool is adapted to interpret an association as such. for example, the system line (1..1) is-composed of (1..n) subsystem could directly be interpreted as describing an association is-composed-of (aggregation).

Example 11

  u: use case name, package name The use case declaration, or use case, is also used to declare a function of the system, which may correspond to one or more use cases.

  Figure 1 shows an example representation of a UML model. With reference to this figure, consider the following example

c: cat, example

c: mouse, example

  r: cat (1..1) eat (1..n) mouse According to the UML notation, the clauses above are represented as illustrated in figure 1. In this figure, the cat and mouse classes are symbolized by labels 10, 20. The corresponding cardinalities 12, 22 appear in proximity. The above relationship (r: cat (1..1) eat (1..n) mouse) is symbolized by the arrow 30.

  Fig. 2 shows a diagram schematically showing certain steps of a data processing method according to an embodiment of the invention.

  Prior to the detailed description of this figure are summarized the guiding ideas that led to the development of the data processing method according to the invention.

  The simplicity of the FIL notation makes it possible to envisage creating a data structure or a file reflecting this notation and this, directly from the analysis of a text written in natural language. The created file can be used as a basis for creating a UML object or for generating a source program, as shown in the following string: (1) text -> (2) data structure in FIL format -> (3) UML object model or 10 source code.

  This idea is based on the following conjecture: the sentences of a text - provided they are constructed according to the canon subject-verbecomplement - express relations between objects in the sense of the object approach. For example, nouns represent objects and verbs express a relation between these objects. We can refer to an example discussed above: a cat eats mice.

  Since objects are instances of classes, it is possible to deduce a relation linking classes to each other from the relation which links these objects, in particular if the articles used are undefined (one or more in place of the one or the) . In the example the blue cat eats the green mouse, it is referred, in both cases (blue cat and green mouse) to a particular instance of the generic classes cat and mouse. Thus, in the example a cat eats mice, it is referred to classes; the relation therefore has a meaning in the object world.

  It should be noted, as a corollary to the conjecture above, that the semantics of a text described using sentences according to the subjectverb-complement type is contained in the syntax of the text itself. In addition, the semantics of the model that one wishes to obtain from a text is contained in the syntax of the language in which this text is written.

  Thus, it is conceivable that it is possible, from a text, to formalize in a simple way, using the text of the sentences themselves, the relations between the objects of the model.

  Another consequence: an appropriate treatment (automatic or semiautomatic) of each sentence of a text makes it possible to formalize the relations between the objects, and to represent them in a formal and simple way using the notation FIL used for a structure of data according to the invention.

  In this respect, the invention proposes a method of data processing implemented at least partially by computer. This method comprises a central processing step 110 of the data structure 60 according to the invention. Valuation means that values corresponding to data are stored (for example in the computer's RAM or on a mass storage medium). A data structure 60 according to the invention can in this way be exploited by computer.

  In particular, the valuation 110 of the data structure 60 can be performed in two stages. It may first be a step of decomposing 100 data into modeling elements of the formalism. Then, a modeling element can be represented (i.e., transformed by computer) into a corresponding clause of the data structure 60. Note that different algorithmic variants can be envisaged. For example, as soon as a modeling element is isolated, it is transformed into a corresponding clause. Alternatively, the elements can be transformed into clauses after each of them has been identified.

  A preferred embodiment of the method according to the invention is described in the following. In this embodiment, the data decomposition step 100 comprises a grammatical analysis of a reference text, eg, the text exposing a given problem or the specification of a system or application.

  The analysis itself can be broken down into seven main steps, which result in a file 50 as described above.

  1) First of all, the analysis of the text includes the division of the text into sentences (the end of a sentence being indicated by a point, a comma or an end-of-paragraph mark).

  2) Then, there is a resolution, enumerations (treatment of terminologies and, or, as well as, either ... or, etc.).

  3) Subordinates are then resolved (introduced by whom, that, of which 30, or, to, aux, etc.).

  At this point, simple sentences have been isolated.

  4) Then, it is eventually proceeded to the elimination of the words to be ignored in each simple sentence, as will be illustrated below.

  5) The canonical forms are solved (singular names, verbs in the infinitive, etc.) 6) Cardinalities are then characterized, as a mark of the singular (1..1) or the plural (1..n) , this in view of the transformation of the sentences into lines FIL.

  7) One proceeds then to the resolution of the values of attributes or types of attributes in the elementary sentences obtained previously and the finishing of the model.

  In the end, elementary sentences are obtained comprising two objects (with their respective cardinalities) separated by a verbal group; these sentences can be converted into FIL clauses for later computer operation.

  The preceding steps can be better understood through the following example, described with reference to FIG. 3, which shows an exemplary representation of a UML model obtained by implementing the data processing method, according to a method of embodiment of the invention, from a reference text.

  This example (example 12) is based on the following reference text: An application is used to invoke basic services, service components or another application that can be downloaded from a remote server. A service component comprises several basic services.

  1) Text splitting into original sentences The text consists of two original sentences, which are identified: (i) An application is used to invoke basic services, service components or another application that can be downloaded from a remote server.

  (ii) A service component comprises several basic services.

  2) Enumeration resolution This processing is based on the results of a grammatical parsing of the sentence, performed using a grammar parser. At the end of the grammatical analysis, a subordinate introduced by the conjunction "which" is detected. The subsequent processing of the text, taking into account the resolution of the enumerations but not that of the subordinates, makes it possible to construct and dispose now of the following three sentences: (i) An application makes it possible to invoke basic services which can be downloaded from a remote server.

  (ii) An application allows to invoke service components that can be downloaded from a remote server.

  (iii) An application allows to invoke another application that can be downloaded from a remote server.

  (iv) A service component comprises several basic services.

  3) Subordinate Resolution This processing is also based on the results of a grammatical analysis of each of these new sentences. During this step, each of the preceding sentences is passed again in the grammar parser, in order to solve the subordinates. Two simple sentences are identified in place of each sentence containing a subordinate. The primary meaning of the text is not betrayed (there is semantic preservation), but the structure of each sentence becomes simpler: one thus approaches little by little a modélisable text. The result of this step is as follows: (i) An application allows you to invoke basic services.

  (ii) Basic services can be downloaded from a remote server.

  (iii) An application allows to invoke service components.

  (iv) Service components can be downloaded from a remote server.

  (v) An application allows to invoke another application.

  (vi) Another application can be downloaded from a remote server.

  (vii) A service component comprises several basic services.

  The result of the grammatical analysis of each sentence can be stored by the operating computer tool mentioned above.

  4) Elimination of non-significant words Each of the simple sentences thus obtained is, now, possibly passed through a filter making it possible to eliminate non-significant words, which are identified by the examination of a specific dictionary, if necessary parameterizable. These words are deleted in order to simplify sentences because they do not provide any relevant information. Here for example, the word other will be deleted in the fifth and sixth sentences.

  (i) An application allows to invoke basic services.

  (ii) Basic services can be downloaded from a remote server.

  (iii) An application allows to invoke service components.

  (iv) Service components can be downloaded from a remote server.

  (v) An application allows to invoke an application.

  (vi) An application can be downloaded from a remote server. (vii) A service component comprises several basic services.

  5) Resolution of canonical forms The result of the grammatical analysis of each simple sentence is kept in memory. The examination of these results makes it possible to determine the canonical forms of substantives and verbs (nouns in the singular, verbs in the infinitive). During this intermediate step, a mark associated with the corresponding number in the sentence is also preserved for each substantive. For example, (sing) to denote the singular, can be placed after the substantive, and (several) to denote the plural, placed before. This choice of disposition has a twofold objective: first, to facilitate the next step, during which cardinalities will be identified, then to help identify associations; Indeed, an association will be formed from the phrase (often a verb) that will be located between the two marks of cardinality. The sentences obtained are as follows.

  (i) application (sing) allow to invoke (multiple) elementary service (ii) elementary service (multiple) can be downloaded from (sing) remote server (iii) application (sing) allow to invoke (multiple) component of services (iv) service component (several) can be downloaded from (sing) remote server (v) application (sing) allow to invoke (sing) application (vi) application (sing) can be downloaded from (sing) remote server ( vii) service component (sing) includes (several) elementary service 6) Cardinality installation A simple process now allows the (sing) and (several) marks to be replaced by the corresponding cardinalities: (1..1) and (1) ..not). Each of the 5 preceding sentences thus becomes a FIL clause: (i) application (1..1) allow to invoke (1..n) elementary service (ii) elementary service (1 .. n) to be downloaded from (7) ..1) remote server (iii) application (1..1) enable to invoke (1..n) service component 10 (iv) service component (1..n) can be downloaded from (1 .. 7) remote server (v) application (7..1) allow to invoke (1..1) application (vi) application (1 .. 1) can be downloaded from (1..1) remote server (vii) service component (7 .. 7) comprises (1..n) elementary service Of course, the two steps (5) and (6) can be seen as a single step.

  7) Values of Attributes and Finishing of the Model This step can group three distinct treatments.

  First, adjectives associated with substantives are searched for and positioned as class attributes (that is, as specific features of that class). This gives rise to the assignment of the codes a for attribute. In addition, the attribute may be associated with the corresponding class.

  Then, class declarations are created automatically for each noun, hence the appearance of FIL c for class. Finally, a package can be associated with each class.

  The FIL code r (for relation) is then associated with each of the FIL clauses describing a relation.

  FIL clauses can then be sorted by type, for readability and presentation purposes, although this is not required. We thus obtain the final FIL model:

p: example

c: application, example

c: service, example

c: service component, example

c: server, example

  a: elementary = TRUE, service a: remote = TRUE, server r: application (1 .. 1) allow to invoke (1..n) service r: service (Ln) can be downloaded from (1..1) server r: application (1..1) allow to invoke (1..n) service component r: service component (1..n) can be downloaded from (1..1) server r: application (1 ..1) allow to invoke (1..1) application r: application (1..1) can be downloaded from (1..1) server r: service component (1..1) is composed of (1..1) 1..n) Service In Figure 3, the above elements are represented in the form of a UML model.

  In this model, the application class is the reference 200. The application class is involved in the relations 210, 220, 230 and 240, according to the elements r mentioned above.

  These relationships link the application class to the application class itself, as well as to service component classes 300, service 400, and server 500, which are in turn involved in relations 305, 310, and 410. service component classes 300 and service, we can note the special relationship: is-composed-of 305, an "aggregation" in UML and which is distinguished graphically from other relations by the presence of a rhombus at the base of the arrow corresponding, as is usual in the art.

  For the service 400 and server classes, the attributes, types, and type values represented in the respective labels 402 and 502 should also be noted, reflecting the decomposition described above.

  Referring now again to FIG. 2, the data processing method according to the invention may comprise, after the recovery step 110, a creation step 120 of an XMI model 70, from the structure 60, via an XMI generator. This XMI generator could for example operate according to the same principle as the code generator mentioned below: after having accessed the contents of the data structure, the generator stores this structure in its own internal memory and then transforms its content according to rules of their own transformation, which are parameterizable and which depend only on the correspondences that we want to establish between two metamodels: on the one hand the metamodel of the data structure FIL itself (input structure), and on the other hand the metamodel of the data structure XMI, Java, C # or C ++ for example (expected structure output). Thus, the generation tool applies, on an internally stored data structure, transformation rules mapping a modeling element of a given metamodel with a modeling element of another metamodel. In this respect, there are tools, such as Sodifrance's Model-In-Action (see the website www.miasoftware.com), which make it possible to build such generators: the two metamodels are described using UML, then the transformation rules using a high-level language, and we get very quickly transformers-generators of language. With such tools, the creation of an XMI model via an XMI generator is possible. In this case, the model 70 is generated from the previously valued data structure 60. Then, a graphical UML model 75 can be produced from the previous XMI model 70, during a model production step 130. The production of a graphical UML model from an XMI model is, as such, known to the art (it is possible, for example, to use tools such as Objecteering or Rhapsody, mentioned above).

  Moreover, the data processing method according to the invention can comprise, after the recovery step 110, a data structure accession step followed by a generation step 140 of a code 80. this step, the data structure is stored and its content is transformed according to parametrizable transformation rules, which depend on the desired matches between two metamodels, like what has been described with reference to the XMI generator. Transformation principles are described, for example, in the book Design Patterns, Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Addison-Wesley Professional, first edition, 1995.

  At the end of this step, Java or C # Classes are generated. These can advantageously be exploited in an integrated service environment. A service environment is an object application development environment that can read Java or C # source classes directly, for example. Step 150 is, in this regard, a simple step of importing these classes 80, correctly generated in a format readable directly by the environment 85.

  The invention is however not limited to the variants described above but is capable of many other variations easily accessible to those skilled in the art.

  For example, it is possible to omit certain steps of the grammatical analysis or to combine them differently.

Claims (15)

  A data structure (60) compatible with an object modeling formalism, the formalism comprising a plurality of modeling elements, wherein: the data structure (60) comprises a plurality of clauses; each of these clauses is associated with one or more modeling elements of the formalism; and - each of these clauses is entirely declarative.   The data structure (60) of claim 1, wherein each of said clauses relates to a single modeling element.   The data structure (60) of claim 1 or 2, wherein each of said clauses includes code relating to the modeling element to which it refers and features relating to that modeling element.   The data structure (60) according to claim 1, 2 or 3, wherein some of said clauses include features relating to a container of the modeling element to which it refers.   The data structure (60) of any one of claims 1 to 5, wherein the object modeling formalism is UML notation.   The data structure (60) according to any one of claims 1 to 5, wherein one of the formalism modeling element is: a package; - a use case or user case; a class; - an attribute; an association; or an inheritance.   A computer program product, adapted to enhance, access and / or manipulate the data structure (60) according to any one of claims 1 to 6.   A computer readable file comprising a representation of the data structure (60) according to any one of claims 1 to 6.   A method of data processing comprising: - a step of upgrading (110) the data structure (60) according to any of claims 1 to 6.   The data processing method according to claim 9, comprising, prior to the valuation step (110): a step of decomposing (100) data into modeling elements of the formalism; and wherein a formalism modeling element is represented as a clause of the data structure (60), during the valuation step (110) of the data structure (60).   The data processing method of claim 10, wherein the step of decomposing (100) data comprises grammatically analyzing a text (50).   The data processing method according to claim 11, wherein the grammatical analysis at the decomposing step (100) comprises each of the following sub-steps: - splitting the text (50) into sentences; enumeration, for example enumerations introduced by and, or, as well as or ... -resolution of subordinates, for example subordinates introduced by whom, whom, of whom, where, to or to; elimination of certain words according to given criteria, at the end of the sub-resolution step of subordinates; - resolution of canonical forms of names; - resolution of cardinalities of names; and - attribute resolution.   The data processing method according to any one of claims 9 to 12, comprising, after the recovery step (110): a step of creating (120) an XMI model (70) via an XMI generator from the data structure (60).   The data processing method according to claim 13, comprising, after the step of creating (120) the XMI model: a step of producing (130) a UML model (75) from the XMI model ( 70) created.   The data processing method according to any one of claims 9 to 12, comprising, after the recovery step (110): a step of accessing the data structure (60); and a step of generating (140) a code (80).