FR2838902A1 - Heterogeneous data access system for software engineering tools uses adaptors with formal grammar for each tool - Google Patents

Abstract

A heterogeneous data access system sets up a formal granule identification grammar and interfaced granule (9, 11) client server adaptor (10, 12) for each tool (6, 7) with direct HTTP (Hyper Text Transfer Protocol), FTP (File Transfer Protocol) or HTTPS (Hyper Text Transfer Protocol Secured) connection of appropriate client (C) and server (S). Includes an Independent claim for use of the system with XML (Extended Mark Up Language) format granules with structured data.

Description

by deleting said modulation.

  METHOD SIMPLIFYING ACCESS TO HETEROGENEOUS DATA

MANAGED BY SOFTWARE TOOLS

  The present invention relates to a method for simplifying access

  has heterogeneous data managed by software tools.

  The invention is implemented in the field of software engineering tools. These tools can be of different types: modeling tools, code generators, test tools, ... The data used by these tools are represented in a proprietary format, which is different from one tool to the other. It follows that the data presented in a tool

  can not be used directly by another tool.

  To allow a tool to export its data to a tool of another type, two methods are currently being carried out: by link

  manual or point-to-point link.

  The manual link is applied when the data emitter tool can export its data in a format acceptable to the receiver. It is then necessary to proceed in two phases, as schematise in figure 1. In a first time t1, one launches the tool OU-1 exporter, and one makes him produce a file of appropriate export F1 (t'1). In a second time (t2), the second tool OU-2 (receiving tool) receiving (t'2), as a working parameter, the F1 file previously exported is launched. The final result R is then elaborated by the tool OR-2 (t3). It is possible that the first tool can not export the requested data at the granular level or in the format desired by the second tool, which then imposes an intermediate phase.

  processing of the F1 export file.

  The major drawbacks of this method are the lack of automation and the risk of error of use at the file level.

  export, which can for example be that generated during a previous export.

  According to the known method of point-to-point connection, an interface specific to both tools is used. As schematized in FIG. 2, an adapter of the data requesting tool OU-3 directly calls (t1) the IP-1 programming interface (<API >>) of the OR-4 tool possessing the data, which produces (t2) the export file F2 asks. The supplier tool OU-4 then sends (t3) an acknowledgment to the calling tool OR-3, which can search (t4) the file exports and use it (t5) to produce the product P. for example. The disadvantage of this method is that each link between provider tool and client tool must be made specific. For example, for the same tool provider of data for five user tools it is necessary to realize five distinct interfaces, the intelligence of each interface being located on the client's side. Since development workshops use a large number of linkages between tools, the result is that coupling development costs, and especially their maintenance costs, can quickly become very important. In addition, any tool evolves over time, resulting in changes in its functionality. It is therefore essential to make each of its couplings evolve to other

1 o tools.

  The present invention relates to a method simplifying access to heterogeneous data managed by software tools, a method that allows the automation of exchanges, which avoids the errors of use of export files, which is not dependent on the the type of link established between the supplier tool and the client tool, whose development and maintenance costs are as low as possible, and which allows the evolution of the tools concerned without having to make all the associated couplings evolve. The method according to the invention is characterized in that one establishes for each tool a formal grammar identification of its granules, which is constituted for each tool a granule server interface with him and that constitutes for each tool a customer gets

  connecting directly to the appropriate granule server.

  The present invention will be better understood on reading the

  detailed description of an embodiment, taken as an example not

  and illustrated by the accompanying drawing, in which: - Figures 1 and 2 mentioned above, wind diagrams used to explain the processes of the prior art; FIG. 3 is a diagram explaining the step of identifying granules of the process of the invention; FIG. 4 is a block diagram of a two-tool architecture implementing the method of the invention; and FIG. 5 is a diagram explaining the creation of a URL for establishing communication between tools according to the method of the invention. To be able to create a universe way! Access to the data of a tool, the method of the invention comprises a first step of defining a formal grammar granules ("Artifacts" in English, or elementary objects) managed by a tool. For example, as schematised in FIG. 3, the granules managed by a UML modeling tool 1 are, in descending order of size, the projects 2 (individual projects, products) which can contain each of the types of diagrams 3 (type sequences , class classes, ...), which can themselves contain classes 4 (elementary classes, class relationships, ...), which, in turn, can contain attributes 5 (physical characteristics, ...) . This grammar makes it possible to know at what level of granularity 2 to 5 are the data required by the calling tool and to define without ambiguity the granules in their context. To enable a data provider tool to properly interpret a request from any calling tool, the invention provides for providing this provider tool with an adapter (granule server) that interfaces with it by means of a API, which is a well-known interface in itself. The roles of the adapter are as follows: it decodes the requests of the calling tools, these requests respecting the formal grammar of the provider tool; it will seek the demand granule through the API programming interface of the tool; and it presents this granule in a standard format allowing its use by the calling tool. This format is for example the XML format, when the corresponding data wind

Structurable data.

  On the side of the calling tool, the adapter is responsible for: building the queries to the data provider tools; and 30. to decode the responses to the requests, for example by launching a copy by FTP from a file address provided

in the answer.

  FIG. 4 shows an example of adapter implementation on two tools 6, 7 communicating via a computer network bus 8. The memory 6A of the tool 6 stores its data in a proprietary format F. The tool 6 includes an API 9, and it is connected to an adapter 10. This adapter 10 may have only a part << server> S if the tool 6 is not intended to be a calling tool, but in the majority of cases, the adapter will advantageously include a "server" part S and a "client" part C. Also, I the calling tool 7 comprises an API 11 and an adapter 12 constitutes a "client" part S. and, where appropriate, a << server >> part S. To obtain data granules held by the 6, the client of the adapter 12 of the tool 7 addresses a request 13 to the tool 6 via the bus 8. This request 13 is in the standard format URL (<Uniform Resource Locator >>). By bus 8, the request reaches (14) the "server" part of the adapter 10, which commands the user to select in its memory 6A the data granule at the required level and to produce a file of XML export 15A. An acknowledgment 15 is transmitted by the adapter 10 to the bus 8. After having transited on the bus 8, the acknowledgment

  reaches (16) to the adapter 12, which interprets it.

  If necessary, the adapter 12 makes a local copy of the XML file by FTP. He then asks tool 7 to transform the XML file, by

example, in C code or Ada (17).

  In Figure 5, the URL format of a query is schematised. This format is the standard URL format, of the form: http: // <o rd in ateu r>: <po rt> / <ch em in>? <search> In this format, we have: <computer>: <port> / <path> = name of the target computer: communication port / name of the target tool etona:? <search►command and identification of the granule according to the specific grammar of the tool in question In Figure 5, the name of the host computer is << the host >>, the name of the tool in question (provider tool) is << rhapsody >>, the name of the communication port is << 205 >> and the << search >> label is broken down as follows: << fetch >>: command << a 380 >>: project name << activity >>: type of diagram << command >>: name of the diagram << robot >>: name of the class lo << timeout >>: name of the attribute The request is therefore a request to export an attribute << timeout >> of the << robot >> class of the << command >> activity diagram,

  which is part of the project "a380".

  Therefore, the use of a standard URL makes it possible to use the standard HTTP or HTTPS (<HTTP Secured>) communication protocol for all the client-server control transactions (granule request and acknowledgment of the request). by the provider tool). The positive acknowledgment of the provider adapter server also contains the address of a file in which the expected result is located. The client of the calling tool can then dispose of it at will

  for example, launching a local copy by FTP.

  The combination of URLs formed from a tool-specific grammar and a specialized adapter to extract the desired granules avoids the use of heterogeneous data formats. Each data provider tool, combined with its adapter, behaves like a perfectly standardized data server. Each user tool (calling tool) has an adapter that is completely independent of the tools called (provider tools). This adapter is responsible for formulating granule requests with a standard URL format based on the public grammar of the called tool, and

  to decode the answers made by the called tool.

  The immediate advantage of the method of the invention is the limited cost of

  development, and especially of the maintenance of the couplings between tools.

  Except for a change in its grammar, which is rare, the evolution of the functionality or implementation of a data provider tool only involves the modification of its adapter. In the typical case of the point-to-point connection, the same evolution of the tool would lead to the modification of all the adapters of the calling tools. For the implementation of the method of the invention, we write adapters preferably in the language JAVA, to ensure maximum portability on different hardware and software platforms. These adapters are connected by a classic client-server relationship. According to an advantageous embodiment, the grammars of the

different tools in XML.

  In summary, queries exchanged wind in HTML format, which is simple to implement and provides a natural support for URLs. The

  Associated protocol is the HTTP protocol, which is simple, universe! and effective.

  For the transfer of the exchange files, the protocol may use FTP.

  Each tool adapter implements its part of a client server protocol.

  Debugging can be done using a standard browser, Netscape Navigator, or Internet Explorer.

example.

Claims (5)

  1. A method simplifying access to heterogeneous data managed by software tools, characterized by the fact that for each tool (6, 7) there is established a formal grammar of identification of its granules, which is constituted for each tool a server (10, 12) of granules interface (9, 11) with it and that is constituted for each tool a client (C) connecting   directly to the appropriate pellet server (S).   2. Method according to claim 1, characterized by the fact that the   link between client and server is done according to the HTTP protocol.   3. Method according to claim 1, characterized by the fact that the   link between client and server is done according to the FTP protocol.   4. Process according to claim 1, characterized in that the   link between client and server is done according to the HTTPS protocol.   5. Method according to one of the preceding claims,   characterized by the fact that the format of the granules is XML when the   corresponding data wind structurable data.