Device and method for generating at least one computer file for producing a graphic interface of an electronic equipment, and related computer program product

A device for generating at least one computer file for producing a graphic interface of an electronic equipment, and related computer program product are disclosed. In one aspect, the generating device includes a creation module for creating a formalized description of the graphic interface in the form of software requirements, each requirement being associated with a graphic object of the graphic interface and being created from a list of resources, and a generation module for generating, from the formalized description, the computer file from among a source code and descriptive documents of the computer code, the source code being designed to be compiled in executable code to produce the part of the graphic interface. The creation module includes a filtering capability configured to select, in particular as a function of the corresponding graphic object, only some resources from among the list of resources.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims benefit under 35 U.S.C. § 119 of French Application No. 14 01209, filed May 27, 2014, which is herein incorporated by reference in its entirety.

BACKGROUND

Field

The described technology relates to an electronic device for generating at least one computer file from among the computer code and at least one descriptive document of the computer code, to produce at least part of a graphic interface of an electronic equipment.

Description of the Related Art

The generating device comprises a creation capability for creating a formalized description of the graphic interface in the form of software requirements, each requirement being associated with a graphic object of the graphic interface and being created from a list of resources. The generating device comprises a generation capability for generating, from the created formalized description, at least one computer file among a source code and at least one descriptive document of the source code, the source code being designed to be compiled in an executable code for the production of the at least part of the graphic interface of the electronic equipment, each descriptive document containing information relative to the software requirements.

The described technology also relates to a method for generating at least one such computer file.

The described technology also relates to a non-transitory computer readable medium including a computer program including software instructions which, when implemented by a computer, implement such a generating method.

The described technology applies to the field of man-machine interfaces for onboard electronic equipment, in particular graphic interfaces of those pieces of onboard equipment, such as aeronautic equipment, railroad equipment, automobile equipment and aerospace equipment.

A generating device and method of the aforementioned type are known from document U.S. Pat. No. 6,681,383 B1.

This document describes a tool for the automatic production of a software program comprising a capability for creating a formal specification, a capability for validating the generated formal specification and a capability for automatic conversion of the validated formal specification into source code.

The formal specification is created in the form of system requirements that are entered using class diagrams, and the generating device comprises a graphic interface for requirement entry, the graphic interface being an object-oriented interface.

This document relates to the field of client-server applications.

The graphic interface is generated in a single step, and the requirements are created from a frozen list of resources.

Such a generating device is suitable for three-phase software development for the descending part of the V-shaped cycle, i.e., the specification, design and production of the code.

Such a generating device validates the completeness and accuracy of the created requirements once those requirements have been converted into the formal specification(s). The designer therefore enjoys considerable freedom of creation during the phase for creating the requirements.

Such a generating device also makes it possible to generate documentation for informational purposes and describing the created source code.

However, such a generating device is not very suitable for generating a graphic interface source code in the field of onboard electronic equipment.

SUMMARY OF THE CERTAIN INVENTIVE ASPECTS

An objective of certain inventive aspects is therefore to facilitate and improve the production of at least part of the graphic interface of the onboard equipment, in particular the generation of the source code for the associated documentation, while helping the designer to create software requirements, then by automatically generating the source code from the created software requirements.

To that end, one inventive aspect is an electronic generating device of the aforementioned type, in which the creation module includes filtering capability suitable for selecting, in particular as a function of the corresponding graphic object, only some resources from among the list of resources.

Owing to the generating device according to certain aspects of the described technology, the designer is assisted in the production of the part of the graphic interface, while being guided as early as possible, in particular as of the entry of the software requirements, the device according to the described technology offering the designer, via the filtering capability, only a limited list of resources for the creation of the software requirements. This makes it possible to ensure as early as possible, as of the creation of the software requirements, that the constraints associated with the graphic interface of the onboard equipment are indeed verified.

According to other advantageous aspects of the described technology, the generating device comprises one or more of the following features, considered alone or according to all technically possible combinations:the device further comprises a compilation module for compiling the generated source code into an executable code, the executable code being able to be executed by the electronic equipment to produce the at least one part of the graphic interface;at least one software requirement includes a field to be completed; and the filtering capability is suitable for selecting only certain resources from among the list of resources further as a function of the type of field;the creation module further includes an acquisition capability, only in the form of a chain of alphanumeric characters, for data of the field;each software requirement is chosen from the group consisting of: an initial display requirement, a display refresh requirement, a requirement of an interaction associated with the graphic object and a processing requirement for an event;the filtering capability is suitable for selecting only some resources from among the list of resources further as a function of the type of the corresponding software requirements;the filtering capability is further suitable for selecting a syntax of the requirement from among several possible syntaxes, in particular as a function of the corresponding graphic object;the filtering capability is suitable for selecting the syntax of the requirement further as a function of the type of the corresponding software requirements;each descriptive document generated by the generation module complies with the requirements of standard RTCA DO-178C,each descriptive document desirably being chosen from the group consisting of: a specification document, a design document and a traceability document for requirements of the specification and/or design documents.

Another aspect is a method for generating at least one computer file from among a computer code and a descriptive document of the computer code, in order to produce at least part of a graphic interface for an electronic equipment, the method being implemented by a computer and comprising the following steps:creating a formalized description of the graphic interface in the form of software requirements, each requirement being associated with a graphic object of the graphic interface and being created from a list of resources,generating, from the created formalized description, at least one computer file from among a source code and a descriptive document of the source code, the source code being designed to be compiled into executable code in order to produce at least part of the graphic interface of the electronic equipment, the descriptive document containing information relative to the software requirements,wherein the creation step further includes filtering the resources in order to select, in particular as a function of the corresponding graphic object, only some resources from among the list of resources.

According to another advantageous aspect of the described technology, the generating method comprises the following feature: the method further comprises, after the generating step, a step for compiling the generated source code in an executable code, the executable code being able to be executed by the electronic equipment in order to produce the at least part of the graphic interface.

The described technology also relates to a non-transitory computer readable medium including a computer program including software instructions which, when implemented by a computer, implement a generating method as defined above.

DETAILED DESCRIPTION OF CERTAIN INVENTIVE EMBODIMENTS

InFIG. 1, an electronic equipment10comprises a first display screen12and a first information processing unit14for example formed by a first processor14and a first memory16associated with the first processor14.

The electronic equipment10is for example an onboard equipment, such as aeronautic equipment, railroad equipment, automobile equipment or aerospace equipment.

The first memory16is able to store a kernel20, also called system core, rendering a list of software services and manipulating core data, a first layer22for standardizing interfaces with the kernel20(core wrapper), making it possible to use software services provided by the kernel20and to consult/modify the core data, and a second layer24for standardizing message management interfaces (message manager). The messages include system messages and user messages, the management of the system messages being done by the core20, and that of the user messages being done by the second standardization layer24. Message management in particular refers to the publication and/or erasure of those messages.

The first memory16is also able to store a first library26of data format, also called data format library, a graphic interface sequencer28(component processing) and a browser30.

The first memory16is also able to store a second library32for defining widgets, also called widget library, a third library34for coding/decoding information, also called coding library, and a protocol manager36. The second and third libraries32,34and the protocol manager36form a layer38for managing the display of data on the screen12.

The first memory16is lastly able to store a specific layer40.

The first standardization layer22, the second standardization layer24, the first library26, the sequencer28, the browser30, the second library32, the third library34, the protocol manager36and the specific layer40are each a software brick.

The software bricks22,24,28,30and40form a man-machine interface (MMI) instance41, also called MMI instance41.

The set of software bricks22to40forms a software component42for managing a graphic interface50of the equipment, the software component42being able to be stored in the first memory16, as shown inFIG. 1. The graphic interface50comprises at least one higher-level element52, also called format, each format52including at least one page54, and each page54including at least one graphic object56, as will be described in more detail below in light ofFIG. 2.

The electronic equipment10then for example includes N screen(s)12able to display a graphic interface50and the memory18includes M man-machine interface instance(s)41each managing a format52, N and M being integers greater than or equal to 1, for example greater than or equal to 2. The values of the numbers N and M are not correlated, N and M having different or equal values.

The first standardization layer22makes it possible to provide standardized management of the interfaces with the kernel20and then provides a generic manner of manipulating the lists and interactive objects.

The second standardization layer24makes it possible to provide standardized processing for the graphic interfaces of the messages, in particular to manage system alert lists generated by the kernel20or user message lists.

The first library26contains information relative to data formats entered or to be displayed through the graphic interface50. The information contained in the first library26is varied and depends on formats. The information relative to each format for example includes a type of format, an authorized value range for the data of the format, a format size. For the formatting of an angle, it is for example necessary to specify the unit of the input value and the output value of the formatting, in order to be converted if necessary. To format numerical data of the core into a string of characters to be displayed, it is for example necessary to specify a maximum number of characters to be kept after the decimal point, or whether it is necessary to fill in 0s to reach a maximum size of the string.

The sequencer28is suitable for receiving, filtering and sequencing the events from the protocol manager36or the kernel20, the events for example being an action by the user on the graphic interface50, a connection/disconnection. The sequencer28is able to address the specific layer40, which in turn will lean on the first library26, the browser30, respectively, the first and second standardization layers22and24, the second library32, to format the data to manipulate, change pages, respectively, recover data or trigger processing in the kernel20, recover/publish/delete messages, modify the properties of graphic objects. After this request, the sequencer28is able to order the protocol manager36to send frames to the screen12.

The browser30is suitable for managing a page history54(FIG. 2) displayed on the screen12, and also for managing display services, such as refreshing or closing pages54.

The second library32is suitable for providing a standardized definition of the display of the graphic interface50ofFIG. 2, in particular widgets, for example according to standard Aeronautical Radio, Incorporated (ARINC)661, or according to standard ARINC739. The second library32in particular includes information relative to the type and properties of the graphic objects.

The third library34provides encoding or decoding services for information contained in the buffer memories, and is then suitable for encoding information intended for the screen12and/or decoding information received from the screen12.

The protocol manager36is suitable for managing the reception, sending, respectively, of frames coming from the screen(s)12, intended for the screen(s)12, respectively. The protocol manager36is in particular suitable for redirecting the communications coming from a screen12toward the sequencer28of the corresponding MMI instance41, and conversely returning the frames delivered by the specific layer40of an MMI instance21to the corresponding screen12.

The protocol manager36comprises a table, not shown, containing a respective identifier for each of the screens12and for each of the MMI instances41, the table providing the link between the screen(s)12and the corresponding MMI instance(s)41.

The protocol manager36is for example in accordance with part 4.0 entitled “Communication Protocol” of standard ARINC661.

The specific layer40is specific to the graphic interface50, and is different from one graphic interface to the next. The specific layer40can be generated by a device60(FIG. 3) for generating at least one computer file from among computer code and at least one descriptive document of the computer code. In other words, the specific layer40corresponds to an executable code compiled from a source code, the source code being able to be generated by the generating device60. The executable code is also able to be compiled by the generating device60and from the generated source code.

The specific layer40contains a list of pages54, a dynamic definition of each of the pages54, the dynamic definition specifying the dynamic behavior of the pages54as a function of services or events handled by the second library32, the browser30, the first and second standardization layers22,24and the first library26.

The specific layer40also contains a context of the graphic interface50, i.e., the data shared between the pages54, a list of user messages and a list of data formats.

This software architecture of the software component42for managing the graphic interface, the component42including the software bricks22to40, then allows a standardized management of the kernel20.

This software architecture also allows a standardized management of the screen12and/or display standards via: the management, by the manager36, of the reception protocol, sending protocol, respectively, of the frames coming from, intended for, respectively, the screen12, the decoding, encoding library34, respectively, for the frames received, to be sent, respectively, and standardized services for manipulating the properties of graphic objects56by the second library32.

This software architecture also allows the management of browsing via the browser30, the management of data formatting to be displayed or entered by the operator via the first library26and the standardized management of messages via the second standardization layer24.

FIG. 2illustrates a static definition of the graphic interface50. As previously described, the graphic interface50comprises one or more formats52, each format52in turn including one or more pages54, and each page54includes one or more graphic objects56.

The format52is similar to a copy grouping together a set of information and interactions consistent in terms of displayed functionalities and graphic output, a first format52for example being dedicated to the cartographical display and a second format52for example being dedicated to the textual display.

Each page54includes a consistent subset of graphic objects56in terms of functionalities, the graphic object56being the lowest-level element and allowing interactions with a user and the display of information intended for the user.

Each graphic object56has properties and interactions, and the controlling of those properties makes it possible to offer the users that information and the interactions.

The graphic object56is for example a label, and it has properties that include a size, position, visibility and associated text. No interaction is associated with the graphic object56when it is a label.

The graphic object56is for example a button, and it has properties in that case that include a size, position, facility, associated text and status relative to the possibility of activating or not activating the button forming the graphic object56. An interaction associated with the graphic object56, when the latter is a button, is a selection of the graphic object56.

The graphic object56is for example an entry field, and it has properties that include a size, position, visibility, default text and status relative to the possibility of activating or not activating the entry field forming the graphic object56. Interactions associated with the graphic object56, when the latter is an entry field, are a publishing input, entering a character, validating an entered string and canceling publishing.

The graphic object56is for example a checkbox, and the properties associated with checkbox are a size, position, visibility, state relative to the possibility of activating or not activating the checkbox forming the graphic object56, and a selection state. The selection state has two possible values, i.e., an active value corresponding to a selected checkbox and an inactive value corresponding to a deselected checkbox. Interactions associated with the graphic object56, when the latter is a checkbox, are a selection of the checkbox when the selection state is in the inactive state, and a deselection of the checkbox when the selection state is the active state.

InFIG. 3, the generation device60comprises a second display screen62, a capability64for entering data and a second information processing unit66for example formed by a second memory68and a second processor70associated with the second memory68.

The entry and selection capability64is suitable in particular for entering alphanumeric characters, and for example includes a keyboard and mouse.

The second memory68is able to store a software application72for creating a formalized description of the graphic interface50in the form of software requirements, each software requirement being associated with a graphic object56and being created from a list of resources74.

In the example ofFIG. 3, the second memory68is configured to store the list of resources74. In an alternative that is not shown, the list of resources74is stored in a memory, not shown, outside the generation device60.

The second memory68is also able to store a software application76for generating, from the created formalized description, at least one computer file from among a source code and at least one descriptive document of the source code.

As an optional addition, the second memory68is able to store a software application78for compiling the generated source code in an executable code, the executable code being able to be executed by the electronic equipment10in order to produce at least part of the graphic interface50. In the described example, the executable code then corresponds to the specific layer40shown inFIG. 1.

The creation software application72, the generation software application76and the compiling software application78each respectively form a creation module, a generation module and a compilation module.

In an alternative, not shown, the creation module72, the generation module76and the compilation module78are made in the form of programmable logic components, such as one or more field-programmable gate array (FPGA), or in the form of dedicated integrated circuits, such as one or more application-specific integrated circuit (ASIC).

The creation module72is suitable for creating the formalized description of the graphic interface50, i.e., for establishing a dynamic definition of the graphic interface50.

This dynamic definition makes it possible to define how the graphic interface50, in reaction to a set of stimulations coming from the user, of the kernel20and/or the screen12, triggers processing operations related to the reception of each of those stimulations, then updates the data displayed on the screen12. Updating the display consists of displaying one or more new pages54or refreshing the current page(s)54, several pages54being able to be displayed simultaneously.

The triggering of the processing operations related to the reception of stimulations is done at different levels of the structure of the graphic interface50. As an example, each format52handles the reception of events coming from a viewing equipment, such as the display screen12, those events for example being the connection or disconnection of the viewing equipment. Each page54handles the reception of stimulations, such as events and order returns (previously activated) coming from the kernel20, the expiration of a time delay (for example, for the periodic refresh of the display), or page events (for example, entering or leaving the page54). Each graphic object56handles the reception of interactions concerning it, such as pressing a button, entering information relative to the graphic object56.

As an optional addition, the display and refresh of the pages54are optimized by using a reference configuration (layout). Introducing the notion of layout makes it possible, after displaying the configuration, to facilitate the refresh of the display by unconditionally redeveloping a restricted subset, known for the configuration, of graphic objects56and associated properties. In one consultation mode, the corresponding page54then has non-modifiable graphic objects56. The layout of each page54can be modified in a modification mode, for which the graphic objects56are editable, their properties being modifiable.

According to one alternative, one manner of refreshing the graphic interface50consists of unconditionally redeveloping all of the properties of all of the graphic objects56, for each event that may modify the graphic interface50. This complete redevelopment, however, consumes computer resources (central processing unit (CPU), random-access memory (RAM)) and may then saturate the communication toward the screen12.

According to another alternative, another manner of refreshing the graphic interface50is to precisely determine, as a function of the context and as a function of the received event, what the graphic objects56are and what properties are to be redeveloped, and redeveloping them accordingly, for each event that may modify the graphic interface50. This redevelopment is optimized, but the calculation of the targeting of the objects56and the properties to be redeveloped also, however, consumes computer resources (CPU).

According to at least one embodiment, the creation module72includes a filtering capability80suitable for selecting only certain resources from among the list of resources74, the selection in particular depending on the corresponding graphic object, or as an optional addition, depending on the event to be specified.

Among the software requirements forming the formalized description of the graphic interface50, at least one software requirement includes a field to be filled in. The creation module72includes, as an optional addition, an acquisition capability82, solely in the form of a string of alphanumeric characters, for data of the field. If applicable, the acquired alphanumeric characters are for example received from the entry capability64. Each field to be completed is completed using the filtering capability80and/or the acquisition capability82.

In the example ofFIG. 3, the creation module72is made in the form of a software application as previously described, and the filtering capability80, the acquisition capability82, respectively, are then made in the form of respective software functions, included in the software application.

The list of resources74comprises types characterized by their class, constraints and associated operators. The class is for example an integer, a floating-point number, a Boolean, a string of characters, a list, a table, or an object. The constraints are for example limits (for integers and floating-point numbers), a size and authorized/prohibited characters (for character strings), possible values (for lists), a size and type of content element (for tables). The operators are for example comparison operators, operation operators, such as mathematical operation operators (multiplication, division, etc.), operators on strings (concatenation, etc.).

The resources are elements included in the libraries26,32,34, the browser30and the standardization layers22,24and accessible by the specific layer40to perform the processing operations for which is responsible.

Generally, each resource contains information relative to: its display as a requirement piece (text pattern), this being useful for generating documentation and display during the creation of requirements; and its technical characteristics, which is useful for generating code, filtering and creating a requirement.

The list of resources74also comprises commands characterized by their complete signature, their type—i.e., synchronous or asynchronous—and by their associated command return if one exists. The signature of a command is the list of input and output parameters of the command, the command for example being a core20service, a browser30command, a second library32command, a message manager34command.

The list of resources74also comprises command returns characterized by their possible end-of-command statuses and their returned data. The command statuses depend on the commands themselves. In general, this will involve forms of “command successful” (or ‘OK’) and “command failed” (or ‘KO’) statuses, or additionally the reason for the rejection related to the core20(saturation of a stack, syntax error, use of data unknown by the core, limit error on a unit, etc.).

The list of resources74comprises events characterized by their associated reasons and the returned data. The reasons for the events are the counterpart of the command statuses. They depend on the event and indicate why that event was raised. An event is generated by the kernel20or by the user via the protocol manager36.

The list of resources74comprises data characterized by the complete signature of the getter, the type of data, the potential presence of an associated validity.

The list of resources74comprises the lists of data characterized by the type of data and the available filters.

The list of resources74comprises interactive events characterized by their type. An interactive event is defined in the form of a global variable, which may be of any type defined in the resources. Additionally, the types of interactive elements are limited to a subset of types based on the graphic interface50.

Additionally, in the particular case of data formatting, the list of resources74further comprises data formatting categories characterized by their name, the parameters of the formatting (name, type), the results of the formatting (name, type). A result of the formatting is the status of the formatting, such as success, format error, out-of-scope. Another result of the formatting depends on the format itself. As an example, for formatting for data to be displayed, this other formatting result is a string of characters of the same type as expected by the property of the graphic object to be filled in. As an additional example, for formatting of entered numerical data, the other result of the formatting is the data converted into the corresponding unit, potentially rounded and therefore of the type extended by the core command to be filled in.

According to this addition relative to data formatting, the list of resources74further comprises data formats characterized by their name, the instantiated formatting category and the values for part or all of the parameters of the instantiated category.

Additionally, in the particular case of messages, the list of resources74further comprises message categories characterized by their name and instantiation right and a structure made up of fields (name, modification right, type).

According to this message-related addition, the list of resources74further comprises messages characterized by their name, modification right and category. A category refers to a set of messages that are managed in the same way. As an example, messages from the ‘user’ category have properties specific to them and may be published or erased by the specific layer40. Messages of the ‘system’ type are characterized differently and do not have commands for publishing them, since they are published directly by the kernel20. The modification rights make it possible to restrict the specifier or designer in the design of the messages via the creation module72. According to the preceding example, the ‘system’ messages are defined by the kernel20and therefore cannot be created, modified, deleted by the specific layer40. Similarly, some of their properties are not modifiable by the specific layer40. Conversely, the ‘user’ messages may be created, deleted and modified by the specific layer40.

The list of resources74is initially a predefined list that characterizes the first and second standardization layers22and24, the libraries32and26, the browser30as well as the static definition of the graphic interface50, defined beforehand. Additionally, the list of resources74is configured to be enriched, in particular by the creation module72, via the addition of particular data lists, messages, data formats and interactive elements.

The generation module76is then suitable for generating, from the formalized description created by the creation module72, at least one computer file among the source code and the descriptive document(s) of the source code.

The generated source code is intended to be compiled, for example via the compilation module78, in an executable code to produce at least part of the graphic interface50of the electronic equipment10.

Each generated descriptive document contains information relative to the software requirements. Each descriptive document generated by the generation module76is for example in accordance with the corresponding requirements of international standard Radio Technical Commission for Aeronautics (RTCA) DO-178C, and is able to contribute to the certification of the corresponding graphic interface50according to international standard RTCA DO-178C.

As an example, the generation module76is then suitable for generating three descriptive documents, i.e., a specification document including high-level requirements, a design document including low-level requirements, and a requirement traceability document for the specification and/or design documents. The traceability document makes it possible for example to verify that each high-level requirement has at least one corresponding low-level requirement. Additionally or alternatively, the traceability document makes it possible to verify the links between source code elements (constants, procedures, source files, types) and low-level requirements. The traceability document then makes it possible to demonstrate that each high-level requirement has indeed been taken into account during the design, and is an important element for the RTCA DO-178C certification. The compilation module78is known in itself, and is suitable for compiling the source code generated by the generation module76in executable code, the executable code for example being designed to be executed by the electronic equipment10, in particular by the first processor16, for the implementation of the graphic interface50.

The filtering capability80is configured to select only certain resources from among the list of resources74, such as the list previously described as an example.

The selection done by the filtering capability80in particular depends on the graphic object56for which the software requirement is created. The selection is for example done based on the properties of the graphic object56.

Each software requirement is chosen from the group consisting of: an initial display requirement, a display refresh requirement, a requirement of an interaction associated with the graphic object and a requirement for processing an event. In other words, the aforementioned group contains the different possible types of software requirements associated with the graphic objects56of the graphic interface.

As an optional addition, the filtering capability80is then configured to select, further as a function of the type of the corresponding software requirement, only some resources from the list of resources74. As an example, in the case of a display refresh requirement, the only available commands for the creation of the software requirement are commands for managing properties of the corresponding graphic object56. As an additional example, in the case of a requirement of an interaction associated with the graphic object, all of the commands are available for the creation of the software requirement except the management commands for the properties of the corresponding graphic object56.

As another optional addition, when the software requirement to be created includes a field to be filled in, the filtering capability80is configured to select only some resources from the list of resources74further based on the type of field to be filled in. As an example, when the software requirement to be created includes a comparison between a first field and a second field, the only data authorized for the second field is data of the same type as that of the first field.

As an optional addition, the filtering capability80is further configured to select a syntax of the requirement from among several possible syntaxes, in particular depending on the corresponding graphic object. Syntax refers to a set of conditioned locutions, each conditioned locution including a conditional operator, such as IF, THEN, ELSE-IF, ELSE, FOR, WHILE, followed by a condition and/or an associated action.

According to this optional addition, the filtering80is desirably suitable for selecting the syntax of the requirement further as a function of the type of the corresponding software requirement.

When the requirement to be created is an asynchronous requirement with at least one command return, the filtering capability80is further suitable for forcing the designer to fill in the expected behavior for each command return. In other words, the filtering capability80is then suitable for blocking the generation, or validation, of such a requirement as long as all of the command returns have not been filled in by the designer.

The operation of the generation device60according to an embodiment will now be explained usingFIG. 4, showing a flowchart of the method according to an embodiment for generating at least one computer file from among the computer code and the descriptive document(s) of the computer code.

During an initial step100, the static definition of the graphic interface50is created, the graphic interface50including, depending on the created static definition, format(s)52, page(s)54and graphic objects56, as previously described in light ofFIG. 2.

During a subsequent step105, the formalized description of the graphic interface50is created in the form of software requirements via the creation module72. This creation step105will be described in more detail subsequently usingFIG. 5.

During the following step110, descriptive document(s) of the graphic interface50are generated automatically via the generation model76, from the formalized description created during step105. In the described example, the documents automatically created correspond to the two specification levels required by standard DO-178C.

During the following step120, the source code of at least part of the graphic interface50is generated automatically via the generation module76, from the formalized description created during step105. In the described example, the generated source code corresponds to that of the specific layer40, the other software bricks22to36of the software component42being pre-existing in this example and desirably being shared from one graphic interface50to the next.

Lastly, during step130, the source code generated during the preceding step120is compiled into executable code via the compilation module78, for example to be loaded in the first memory18of the electronic equipment10, then to be executed by the first processor16, so as to implement the graphic interface50.

The step for creation of the formalized description105will now be described in light ofFIG. 5.

The creation step105comprises a sub-step200for selecting a format52, then for each selected format52, building software requirements specifying the processing to be done upon reception of each event coming from a viewing equipment, such as the first screen12, that construction being done via a sub-step210for selecting an event, then a sub-step220for creating the software requirements for the selected event.

The creation step105next comprises, for each selected format52, a sub-step230for selecting a corresponding page54. For each selected page54, the creation step105comprises a sub-step240for defining layouts, also called reference arrangements. For each selected page54, the creation step105comprises the construction of the software requirements specifying the processing operations done upon reception of each event and each command return coming from the kernel20, and each page event, this construction being done via a sub-step250for selecting an event, then a sub-step260for creating the software requirements for the selected event.

The creation step105next comprises, for each selected page54, a sub-step270for selecting a graphic object56.

For each selected graphic object56, the creation step105then comprises the construction of the software requirements specifying the processing operations to be done upon receiving each of the interactions associated with the corresponding graphic object56, as well as the updates of the properties of the graphic object56to be done upon reception of the display and page refresh commands for each layout, this construction being done via a sub-step280for selecting an event, then a sub-step290for creating the software requirements for the selected event.

When the requirement to be created is a requirement including at least one command return, then the filtering capability80forces the designer to fill in the expected behavior for each command return. The field of a corresponding command return is, if needed, completed by information indicating a lack of action, such as information called “NOTHING_TO_DO”, when there is nothing to do for the associated command return.

During the creation step105, the creation module72allows the user to create the corresponding software requirements via a man-machine interface, not shown, divided into four zones as an example. A first zone makes it possible to select or view the element to be published, i.e., the format52, the page54or the graphic object56, for the construction of the software requirements. A second zone makes it possible to publish, i.e., to create or modify, the requirement for the element selected among the format52, the page54and the graphic object56. A third zone shows the available resources among the list of resources74for publishing the requirement. In other words, the resources presented in this third zone are the resources previously selected by the filtering capability80. Lastly, a fourth zone makes it possible to browse the formalized description during creation, while presenting the result of a search, the result of a compilation, the elements related to that selected in the form of hyperlinks.

Thus, with the generation device60according to at least one embodiment and the associated generation method, the designer is assisted in the production of the graphic interface50, while being guided as early as possible, in particular as of the creation of the software requirements, the generation device60offering the designer only a limited list of resources for the creation of the software requirements, the limited list having been filtered by the filtering capability80.

This also makes it possible to ensure as early as possible, i.e., as of the creation of the software requirements, that the constraints associated with the graphic interface of the onboard equipment10are indeed verified, and not only once those requirements have been converted into the formal specification(s) as is done with the device of the state of the art.

The list of resources74is further configurable and able to be enriched by the generation device60, in particular by the creation module72.

The software requirements are directly entered in text form and are considered to be formal specifications.

The graphic interface50is then created using a two-step process, i.e., a static definition, followed by a dynamic definition, the static definition of the graphic interface50including the structuring of the graphic interface50around format notions52containing pages54, those pages54in turn being made up of graphic objects56. The dynamic definition of the graphic interface50corresponds to the step105for creating the formalized description of the graphic interface50.

The generating device60includes a man-machine interface for entering textual requirements by selection.

The generation device60covers and then facilitates the industrial development of software in five phases for the descending part of the V-shaped cycle, i.e., the client specification, the system specification, the formal software specification, the design specification and the generation of the code.

Lastly, the generation device60is qualified, guaranteeing that what is defined in the generated document is fully implemented, and that what is implemented is fully specified. The generation device60therefore makes it possible to save on the review and test phases related to standard RTCA DO-178C.

The generation device60lastly makes it possible to decrease the production cost of the graphic interface50, to guarantee the compliance of the generated code with generated specification (and vice versa), and to reduce the certification effort for the generated code and the associated documentation.

One can thus see that the generation device60and generation method according to at least one embodiment make it possible to facilitate the production of at least part of the graphic interface50, in particular generation of the source code or the associated documentation, by helping the designer to create software requirements, then by automatically generating the source code and/or the associated documentation from the created software requirements.

As can be appreciated by one of ordinary skill in the art, each of the modules or software of the program(s) can include various sub-routines, procedures, definitional statements, and macros. Each of the modules are typically separately compiled and linked into a single executable program. Therefore, any description of modules or software is used for convenience to describe the functionality of the system. Thus, the processes that are undergone by each of the modules may be arbitrarily redistributed to one of the other modules, combined together in a single module, or made available in a shareable dynamic link library. Further each of the modules could be implemented in hardware.

While there have been shown and described and pointed out the fundamental novel features of the invention as applied to certain inventive embodiments, it will be understood that the foregoing is considered as illustrative only of the principles of the invention and not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obvious modifications or variations are possible in light of the above teachings. The embodiments discussed were chosen and described to provide the best illustration of the principles of the invention and its practical application to enable one of ordinary skill in the art to utilize the invention in various embodiments and with various modifications as are suited to the particular use contemplate. All such modifications and variations are within the scope of the invention as determined by the appended claims when interpreted in accordance with the breadth to which they are entitled.