A method and device for generating embedded component entity

Abstract

The present invention discloses a method and device for generating an embedded component entity, and relates to the field of embedded software technology. It is used to solve the problem of long development process time of existing development technology. The component entity generation method includes: obtaining a compilation instruction and a component description file to be compiled carried by the compilation instruction, and generating an intermediate representation for storing the component description file reduction according to the component description file to be compiled; the first keyword entity generates a C++ language component code framework according to the framework mapping rule, and the C++ language component code framework is compiled to generate a component entity; the component entity is stored in the component directory included in the C++ language component code framework.

Description

Technical Field

[0001] The present invention relates to the field of embedded software technology, and more specifically to a method and device for generating an embedded component entity. Background Art

[0002] The command and control system software is a typical distributed embedded software system. With the continuous enhancement of embedded software system functions, the scale and complexity of embedded software are also increasing rapidly. How to improve the design and development process of embedded software, improve development efficiency and enhance product quality has become a hot topic in embedded software research. As a very promising solution, component-based software development methods have gradually been applied in the development of large-scale embedded software systems.

[0003] At present, the component models for embedded system components mainly include: Koala model, PBO model, eCos model, PECOS model, CCM model, etc. The main methods in the field of component testing include: component verification method, component test bench method, metadata-based component testing method, built-in testing method, etc.

[0004] Koala is a component model designed and used by Philips for software development in the consumer electronics field. Koala components have three interfaces: Provides, Requests, and Diversity. Interfaces are defined by the interface definition language IDL. Components are connected through interfaces, which are mapped to a collection of functions. The disadvantage of Koala is that it does not provide explicit support for component testing and debugging, and relies on specific operating systems and compilers. Its modeling language is defined and developed internally, and its importability is poor.

[0005] PBO (Port Based Object) is a component model of system modules in real-time applications proposed by the Department of Computer Science at the University of Maryland. PBO encapsulates the functional implementation of this module. For the outside world, it is recognized and interacted with through the interface. Input variables, output variables, initialization configurable parameters and resource ports constitute the interface of the PBO component model. PBO accepts some variables to be processed and outputs some processed variables. The output variables of a component can be the input variables of one or more components, so that the components can be connected and can work together to form a system. At system startup, the system configures each PBO module through the configuration information of different components to form a complete system. Its disadvantage is that the model depends on the real-time operating system Chimera and cannot be transplanted.

[0006] eCos (Embedded Component Operating System) is a custom library and library management tool for embedded systems developed by Red Hat. It is used for custom development of embedded application systems, including embedded operating systems and applications. eCos uses a hierarchical component description language (CDL) to describe system information. The four basic elements of CDL are: package, component, option, and interface. A package can contain multiple components, a component includes multiple options, and an interface can be implemented by multiple options.

[0007] The PECOS model is a component model applied to fieldbus technology. It defines independent components, subcomponents, and connectors, assembles components into field devices, and checks the structure of component combinations and field devices and their QoS attributes. Within the PECOS framework, Timed Petri Net can be used to describe the temporal characteristics of component behavior, and behavior prediction based on temporal characteristics and generation of real-time scheduling strategies can be performed with tool support. The disadvantage is that there is not enough CASE tool support, and PECOS components are black box components, which affects the openness requirements.

[0008] In summary, the existing component entity generation has the problem of long development technology development process time. Summary of the invention

[0009] The embodiment of the present invention provides an embedded component entity generation method and device, which are used to solve the problem of long development process time of existing development technology.

[0010] An embodiment of the present invention provides a method for generating an embedded component entity, comprising:

[0011] Obtaining a compile instruction and a component description file to be compiled carried by the compile instruction, and generating an intermediate representation storing the component description file reduction according to the component description file to be compiled; wherein the component description file reduction records at least one element included in the component description file to be compiled and basic information of the element through a first keyword entity; the component description file to be compiled defines an ECOM component metamodel through elements;

[0012] The first keyword entity generates a C++ language component code framework according to a framework mapping rule, and the C++ language component code framework is compiled to generate a component entity; and the component entity is stored in a component directory included in the C++ language component code framework.

[0013] Preferably, the compile instruction further carries the compile switch, and the compile switch includes a first compile switch, a second compile switch and a third compile switch;

[0014] The first compile switch is used to set the storage path of the component description file to be compiled. When the first compile switch includes multiple ones, each of the first compile switches corresponds to a storage path of the component description file to be compiled;

[0015] The second compile switch is used to set a first output path of the C++ language component code framework, and before outputting the C++ language component code framework, the first output path needs to be scanned;

[0016] The third compilation switch is used to set a designated output path for the C++ language component code framework, and directly output the C++ language component code framework to the designated output path.

[0017] Preferably, generating an intermediate representation in a memory according to the component description file to be compiled specifically includes:

[0018] Reading characters included in the component description file to be compiled in sequence, analyzing the characters to obtain words corresponding to the characters, and arranging the words in rows to form a component description file without comments;

[0019] Among them, if the comment character / / is read in, all the words obtained by analyzing the characters after the comment character / / are empty until a newline character is read in; if the comment / * is read in, all the words obtained by analyzing the characters after the comment character / * are empty. When a newline character is read in, the line number corresponding to the newline character is written as "+1" until the comment character * / is read in.

[0020] Preferably, generating an intermediate representation in a memory according to the component description file to be compiled specifically includes:

[0021] Scan the unannotated component description file line by line, and when the first word read in matches an element, add the first word and basic information of the first word to a first keyword entity corresponding to the element; add a pointer to the first keyword entity to a component description file reduction corresponding to the unannotated component description file, and add a definition of the first keyword entity in the component description file reduction;

[0022] If the read second word does not match the element name, generating a first keyword entity according to the second word and adding it to the component description file for reduction;

[0023] Among them, the elements include at least: component, interface, port, enumeration, structure, union; the first keyword entity includes at least: component entity, interface entity, port entity, enumeration entity, structure entity, union entity.

[0024] Preferably, the framework mapping rule includes any one or more combinations of the following:

[0025] Basic data type mapping, enumeration entity type mapping, sequence entity type mapping, structure entity type mapping, port entity type mapping, interface entity type mapping, component entity type mapping.

[0026] Preferably, the ECOM component meta-model at least includes a component, and the component includes N component parameters, N component attributes, N interfaces and N ports, wherein N is a natural number.

[0027] Preferably, the C++ language component code framework includes an include directory, a sources directory and a component directory;

[0028] The include directory generates a C++ header file with the same name as the component description file to be compiled;

[0029] The sources directory generates a C++ source file with the same name as the component description file to be compiled;

[0030] The component directory generates a subdirectory that is consistent with the name of the component description file to be compiled, and the subdirectory is used to store the component entity corresponding to the name of the component description file to be compiled.

[0031] The embodiment of the present invention further provides an embedded component entity generation device, comprising:

[0032] A first generating unit is used to obtain a compile instruction and a component description file to be compiled carried by the compile instruction, and generate an intermediate representation storing a reduction of the component description file according to the component description file to be compiled; wherein the component description file reduction records at least one element included in the component description file to be compiled and basic information of the element through a first keyword entity; the component description file to be compiled defines an ECOM component metamodel through elements;

[0033] The second generating unit is used for the first keyword entity to generate a C++ language component code framework according to a framework mapping rule, and the C++ language component code framework is compiled to generate a component entity; and the component entity is stored in a component directory included in the C++ language component code framework.

[0034] Preferably, the compile instruction further carries the compile switch, and the compile switch includes a first compile switch, a second compile switch and a third compile switch;

[0035] The first compile switch is used to set the storage path of the component description file to be compiled. When the first compile switch includes multiple ones, each of the first compile switches corresponds to a storage path of the component description file to be compiled;

[0036] The second compile switch is used to set a first output path of the C++ language component code framework, and before outputting the C++ language component code framework, the first output path needs to be scanned;

[0037] The third compilation switch is used to set a designated output path for the C++ language component code framework, and directly output the C++ language component code framework to the designated output path.

[0038] Preferably, the first generating unit is specifically used for:

[0039] Reading characters included in the component description file to be compiled in sequence, analyzing the characters to obtain words corresponding to the characters, and arranging the words in rows to form a component description file without comments;

[0040] Among them, if the comment character / / is read in, all the words obtained by analyzing the characters after the comment character / / are empty until a newline character is read in; if the comment / * is read in, all the words obtained by analyzing the characters after the comment character / * are empty. When a newline character is read in, the line number corresponding to the newline character is written as "+1" until the comment character * / is read in.

[0041] The embodiment of the present invention provides an embedded component entity generation method and device, the method comprising: obtaining a compile instruction and a component description file to be compiled carried by the compile instruction, generating an intermediate representation storing the component description file reduction according to the component description file to be compiled; wherein the component description file reduction records at least one element included in the component description file to be compiled and the basic information of the element through a first keyword entity; the component description file to be compiled defines an ECOM component metamodel through elements; the first keyword entity generates a C++ language component code framework according to a framework mapping rule, and the C++ language component code framework is compiled to generate a component entity; the component entity is stored in a component directory included in the C++ language component code framework. The component entity generation method can effectively improve the speed of software development and improve the efficiency of software development. At the same time, it can shield the differences between heterogeneous networks and operating systems, decouple business logic from underlying services, and enable developers to focus more on the implementation of business logic without excessively understanding the underlying implementation details. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0043] Figure 1 A schematic diagram of a flow chart of an embedded component entity generation method provided by an embodiment of the present invention;

[0044] Figure 2 A schematic diagram of the ECOM component metamodel structure provided by an embodiment of the present invention;

[0045] Figure 3 A schematic diagram of the software unit interaction process provided by an embodiment of the present invention;

[0046] Figure 4 A schematic diagram of the intermediate representation algorithm flow provided by an embodiment of the present invention;

[0047] Figure 5 A schematic diagram of a C++ language component code framework structure provided by an embodiment of the present invention;

[0048] Figure 6 A schematic diagram of the structure of an embedded component entity generation device provided by an embodiment of the present invention; DETAILED DESCRIPTION

[0049] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0050] Figure 1 A schematic diagram of a flow chart of an embedded component entity generation method provided by an embodiment of the present invention, such as Figure 1 As shown, the method mainly includes the following steps:

[0051] Step 101, obtaining a compile instruction and a component description file to be compiled carried by the compile instruction, and generating an intermediate representation storing the component description file reduction according to the component description file to be compiled; wherein the component description file reduction records at least one element included in the component description file to be compiled and basic information of the element through a first keyword entity; the component description file to be compiled is used to define an ECOM component metamodel;

[0052] Step 102: the first keyword entity generates a C++ language component code framework according to a framework mapping rule, the C++ language component code framework is compiled to generate a component entity; and the component entity is stored in a component directory included in the C++ language component code framework.

[0053] Before introducing the component entity generation method provided by the embodiment of the present invention, it is necessary to first introduce the ECOM component metamodel, component description and component description file.

[0054] like Figure 2 As shown in the figure, the ECOM component metamodel mainly includes 11 elements, namely component (Component), component attribute (ComAttribute), interface (Interface), port (Port), component parameter (ComParameter), operation (Operation), structure (Struct), union (Union), sequence (Sequence), enumeration type (Enumeration) and basic data type (Fundamental Types).

[0055] It should be noted that the core component of the ECOM component metamodel is the component, followed by component attributes, interfaces, ports and component parameters with structured data characteristics; other auxiliary meta-objects include operations, structures, unions, sequences, enumeration types and basic data types.

[0056] The following is an introduction to the basic information of the above 11 elements:

[0057] 1) Components

[0058] A component can contain zero or more component parameters, zero or more component properties, zero or more interfaces, and zero or more ports.

[0059] In the embodiment of the present invention, the interfaces included in the component are divided into Provide interfaces that provide services to the outside of the component and Require interfaces that require services from other external components; the ports included in the component are divided into Publish ports that publish data to the outside and Consume ports that receive data published by other components.

[0060] A component definition can include zero or more other defined components. This is a component combination mechanism that supports the combination of existing components into larger components, thereby forming a hierarchical relationship based on inclusion between components so that users can grasp and use components at different levels.

[0061] 2) Component parameters

[0062] Component parameters can only be set when creating a component instance. They are used to specify the working parameters and working mode of the component, such as working in BIT mode, ground test mode, etc.

[0063] It should be noted that in actual applications, a component instance does not refer to a specific component, but to a certain component. A component instance is actually a real existence of a component. A component is a virtual thing, and a component instance realizes the reality of the component.

[0064] Component parameters can only have primitive data types or enumeration types.

[0065] 3) Component attributes

[0066] Component attributes are used to represent the state displayed by the component and are used by the component's internal business logic. Component attributes must be set when the component is initialized, and can also be set by the component's internal business logic process during component operation.

[0067] Attributes can only have primitive data types or enumeration types.

[0068] 4) Ports

[0069] Ports are the mechanism by which components communicate data with other external components.

[0070] A component can have zero or more Publish ports, each of which is used to publish data to other external components. The definer, developer, and implementer of a component does not need to know which components subscribe to the data published by the Publish port.

[0071] A component can also have zero or more Consume ports, each of which is used to subscribe to data published by the Publish ports of other external components. The definer, developer, and implementer of a component does not need to know which component published the data received by the Consume port.

[0072] Both the Publish port and the Consume port must specify a data type. The associated data type can be a basic data type, enumeration type, structure type, sequence, or union data type.

[0073] When assembling components to form a specific application, you need to specify the corresponding connection relationship between the Publish ports and Consume ports of different component instances. The correspondingly connected Publish ports and Consume ports must be associated with compatible data types.

[0074] 5) Interface

[0075] The interfaces included in the component are divided into Provide interface that provides services to the outside of the component and Require interface that requires services from other external components.

[0076] The Provide interface of a component is used to provide services to the outside, while the Require interface indicates the need to call the services provided by the corresponding interfaces of other components. An interface can contain one or more operations.

[0077] When assembling an application from components, the Provide interface of a component can be connected to the Require interfaces of multiple other components; while the Require interface of a component can only be connected to the Provide interface of another component.

[0078] 6) Operation

[0079] Operations are part of a component interface and are in the form of functions.

[0080] Each operation can have zero or more parameters and a return value.

[0081] The types of parameters and return values ​​can be basic data types, enumeration types, structure types, sequence types, or union data types. Void can also be used to indicate no return value.

[0082] The parameters in an operation can have three transmission mode indicators: in, out, and inout. Specifically, the in indicator indicates that the corresponding parameter is an input parameter, that is, the parameter substituted into the operation is used for the business process of the operation, but the value of the substituted parameter cannot be changed. The out indicator indicates that the corresponding parameter is an output parameter. The value of the parameter cannot be used in the business process of the operation, but the result can be passed (output) to the caller through the parameter. The inout indicator indicates that the corresponding parameter is both an input parameter and an output parameter, that is, it has the characteristics of both input and output parameters.

[0083] 7) Basic data types

[0084] The meaning of the basic data types is the same as that of the basic data types in the CORBA IDL specification.

[0085] 8) Enumeration Type

[0086] An enumeration data type is a simple data type that specifies a finite number (at least one) of named symbolic values.

[0087] 9) Structure

[0088] A structure represents the structural type of the ECOM component metamodel. A structure can have one or more data members, called the attributes of the structure. The data type of each attribute can be a basic data type, an enumeration type, a structure type, or a union data type.

[0089] 10) Consortium

[0090] A union represents the union type of the ECOM component metamodel. A union can have one or more data members, called union attributes. The data type of each attribute can be a basic data type, an enumeration type, a structure type, or a union data type.

[0091] 11) Sequence

[0092] Sequence represents the sequence type of the ECOM component metamodel. A sequence type can be divided into a fixed-length sequence and an indefinite-length sequence. The attribute types in the sequence must be consistent. The data type of each attribute can be a basic data type, an enumeration type, a structure type, or a union data type.

[0093] In the embodiment of the present invention, the ECOM component metamodel describes the above multiple elements and the relationship between the multiple elements. It should be noted that Figure 2 The ECOM component metamodel shown includes 11 elements, but in actual applications, the ECOM component metamodel may only include a few of the above 11 elements, that is, the embodiment of the present invention does not limit the specific number of elements included in the ECOM component metamodel.

[0094] In practical applications, the ECOM component metamodel defined by the UML extension mechanism is a visual and easy-to-read model, but the grammar of the component model expressed by it is not strict, and a more strict context-free grammar is needed to further accurately define the ECOM component metamodel. In the embodiment of the present invention, the ECOM component metamodel uses the BNF production formula to define the grammar of the ECOM component metamodel, and BNF uses the writing method specified by YACC. The starting symbol of the grammar is CDL_declare, and the component description language defined by the grammar is referred to as CDL (Component Description Language) language in this specification. Among them, the alphabet used by the CDL language is the ASCII standard character set.

[0095] Among them, the terminals of CDL language are divided into named terminals and unnamed terminals. There are 29 named terminals in total, listed as follows:

[0096] ENUM Identifier

[0097] VOIDIN OUT INOUT INTERFACE SHORT UNSIGNED LONG FLOATDOUBLE CHARBOOLEAN OCTET STRING CONSUME PUBLISH PROVIDEREQUIRE PORT COMPONENT STRUCTUNION SEQUENCE

[0098] Unnamed terminals are delimited by single quotes in BNF productions. The lexical requirements for named terminals are as follows:

[0099] 1)Identifier

[0100] Identifiers in the CDL language are required to be strings of symbols starting with a letter or an underscore, and the symbols after the first symbol must be letters, numbers, or underscores. All named terminals in the CDL language, except NAME_DELIMITER, must conform to the grammatical requirements of identifiers.

[0101] All named terminators except Indentifier are called reserved words.

[0102] From the perspective of lexical analysis, identifiers other than reserved words are used by component definers to name the components they define.

[0103] 2) CDL reserved words

[0104] The lexical symbol strings corresponding to CDL reserved words are the same as the lexical names of the reserved words, but must be all lowercase letters. CDL reserved words are not allowed to be used in component names, interface names, port names, structure names, type names, enumeration type names, component member names, operation names in interfaces, parameter names in interface operations, value symbol names in enumeration types, etc.

[0105] In the embodiment of the present invention, the ECOM component metamodel describes the elements that need to be present in the ECOM component metamodel and the relationship between the elements, and the ECOM component metamodel is only an abstract description, not a specific thing. The component description (CDL) is a description of a specific component, that is, a specific description of the elements corresponding to the component, the basic information of each element, and the relationship between each element and the component.

[0106] In practical applications, a component description may include multiple components or only one component. In the embodiment of the present invention, the component description is referred to as a component description file.

[0107] It should be noted that the executor of the embodiment of the present invention is a processor, that is, when the processor receives a compilation instruction input from the outside, it parses and generates a C++ language component code framework according to the relevant content carried by the compilation instruction, and further generates a component entity according to the C++ language component code framework.

[0108] In step 101, a compile instruction is obtained from outside. In actual application, the compile instruction carries at least a component description file to be compiled, that is, the processor performs lexical analysis and syntax analysis on the received component description file to be compiled to obtain an intermediate representation.

[0109] Specifically, the process can be combined with Figure 3 The software unit interaction flow diagram provided is introduced in detail:

[0110] like Figure 3 As shown, Figure 3 The software shown includes: a main control unit, a CDL lexical analysis unit, a CDL syntax analysis unit, an intermediate representation unit and a component code framework generation unit. It should be noted that the above five units can all be understood as data interaction within the processor.

[0111] Step 101-1: The main control unit first calls the intermediate representation unit, and according to the compilation instruction obtained from the outside, stores the input file name (the file name of the component description file to be compiled), the output path name and the indication of whether to overwrite obtained from the compilation switch instruction into the intermediate representation IR data structure. At the same time, the main control unit opens the component description file to be compiled and saves its file pointer as a global variable to facilitate the lexical analysis unit to use this file pointer to scan the component description file to be compiled and perform lexical analysis.

[0112] Specifically, the compilation switches are divided into setting the input path, setting the output path, and whether to specify overlay generation.

[0113] -i compilation switch: specifies the input path of the component description file to be compiled (the storage path of the component description file to be compiled). There can be multiple -i compilation switches, that is, multiple input paths are specified. If multiple input paths are specified, and the specified input path contains multiple component description files to be compiled, an error will be reported because the software is not sure which component description file to be compiled. If the -i compilation switch is not used, the CDL compiler only searches in the default path.

[0114] -o compile switch: specifies the output path of the generated C++ language component code framework. The -o compile switch is the output path specified immediately after the parameter. There can be multiple -o compile switches, but the C++ language component code framework is only generated in the output path after the last -o compile switch instruction. If the component modeler does not use the -o compile switch, the C++ language component code framework can only be generated in the default path.

[0115] -f compilation switch: specifies the overwrite generation of the C++ language component code framework. No parameters are required after the -f parameter. If the -f compilation switch is used, the component code generation tool does not scan the output path for the C++ language component code framework related to the component description file to be compiled, and directly generates the C++ language component code framework under the output path. If the -f compilation switch is not used, the component code generation unit scans the output path for the C++ language component code framework related to the component description file to be compiled: if it exists, the C++ language component code framework is not generated; if it does not exist, the C++ language component code framework is directly generated under the output path.

[0116] Step 101 - 2 : The main control unit calls the syntax analysis unit to perform syntax analysis on the non-annotated component description file corresponding to the input component description file to be compiled.

[0117] The lexical analysis unit reads characters from the component description file to be compiled, analyzes them, obtains the non-comment component description file, and then passes the words included in the non-comment component description file to the syntax analysis unit. Each time the syntax analysis unit calls the lexical analysis unit, it obtains a word (token) from the input CDL file stream.

[0118] In addition, another important function of the lexical analyzer is to delete comments.

[0119] When the lexer encounters a comment marker:

[0120] If it is the identifier " / / ", the lexical analysis unit enters the single-line comment mode. In this mode, all words encountered by the lexical analysis are considered empty until a newline character is encountered.

[0121] If the identifier is " / *", the lexical analysis unit enters the multi-line comment mode. In this mode, all words encountered by the lexical analysis are considered empty, and the line number needs to be marked +1 when a newline is encountered. This mode continues until the identifier "* / " is encountered. For the case of " / *...* / ...* / ", the lexical analysis unit will delete the content between " / *" and the first "* / ".

[0122] Step 101-3: During the syntax analysis process, the syntax analysis unit continuously calls the lexical analysis unit, obtains words from the non-commented component description file, and performs syntax checking and semantic analysis on the input word stream. The lexical analysis unit uses the pointer of the component description file to be compiled saved by the main control unit to read characters from the input non-commented component description file, analyzes them, and then passes the analyzed words to the syntax analysis unit.

[0123] Step 101 - 4 : During the syntax analysis process, the syntax analysis unit calls the intermediate representation unit to fill the component definition information of the non-annotated component description file that has been analyzed and collected into the intermediate representation data structure (IR).

[0124] The intermediate representation generation algorithm is as follows Figure 4 As shown, the task of the intermediate representation generation algorithm is to record the ECOM component metamodel defined in the component description file to be compiled into the IR data structure to facilitate the use of the component code framework generation unit. The syntax analysis unit fills the IR interface to fill in the content of the intermediate representation data structure. Whenever the component description file analysis process to be compiled completes the component description file reduction of a CDL entity (component entity) definition, the definition of the component entity is added to the CDLEntity list of the current CDLFile accordingly. According to the type of component entity reduced by the current component description file, it creates and records the relevant properties and methods of Component, Port, Interface, Enum, Struct and Union in the component description file to be compiled.

[0125] Specific as Figure 4 As shown:

[0126] Step 101-401, the syntax analysis unit scans the non-annotated component description file;

[0127] Step 101-402, determining whether the unannotated component description file contains an import instruction, if there is an import instruction, executing step 101-403; if there is no import instruction, executing step 101-404;

[0128] Step 101-403, push the current component description file into the to-be-processed stack, search for the imported build description file in the same directory, and go to step 101-401 again to process the newly found component description language.

[0129] Step 101-404, if a comment is encountered during scanning of the component description file, the comment is skipped and the next line is scanned.

[0130] Step 101-405, scanning the words contained in the unannotated component description file to determine whether the read-in word matches the first keyword name included in the keyword entity; if it matches, executing step 101-406; if it does not match, executing step 101-408;

[0131] Step 101-406, determining the word that matches the first keyword name as the first word, and then adding the first word and basic information of the first word to the matching first keyword entity.

[0132] Step 101-407, adding a first keyword entity pointer to a component description file reduction corresponding to the unannotated component description file, and adding a definition of the first keyword entity in the component description file reduction.

[0133] Step 101-408, determining the word that does not match the first keyword name as the second word, generating a first keyword entity according to the second word, and adding the new first keyword entity to the component description file reduction.

[0134] Step 101-409, determining whether the processing of the unannotated component description file is completed, if not completed, executing step 101-401; if completed, executing step 101-410;

[0135] Step 101-410, determine whether the stack to be processed is empty, if it is empty, the process ends; if it is not empty, the top file of the stack to be processed is popped out and set as the current, and execute step 101-401.

[0136] It should be noted that the first keyword name here at least includes component, interface, port, enumeration, structure, and union.

[0137] Step 101-5: After completing all syntax analysis of the input uncommented component description file, all the component description information given by the component description file to be compiled has been recorded in the IR. At this time, the main control unit calls the component framework code generation unit to generate a C++ language component code framework.

[0138] In step 102, consistent with step 101-5, the component code framework generation unit calls the intermediate representation unit, which stores the component description file reduction, which includes the first keyword entity, and the first keyword entity generates a C++ language component code framework according to the framework mapping rule.

[0139] In the embodiment of the present invention, the framework mapping rules mainly include the following:

[0140] 1) Basic data type mapping

[0141] There are 12 basic data types in the CDL language. The mapping rules between them and the C++ basic data types are shown in Table 1.

[0142] Table 1 C++ mapping of CDL basic data types

[0143]

[0144]

[0145] These basic data types do not need to be specifically defined in the generated code framework file. Only when they appear in other types (port, interface, struct, etc.), these basic data types are used in C++ code according to the above mapping rules.

[0146] 2) Enumeration entity type mapping

[0147] The syntax of enum entity definition in CDL language is consistent with enum type in C++, and only requires direct mapping.

[0148] 3) Sequence entity type mapping

[0149] In CDL language, you can define sequence entity types, which are consistent with vector types in C++. There are two forms of definition, as shown below:

[0150] Vector form 1:

[0151] sequence <x>Cars;

[0152] Vector form 2:

[0153] sequence<X,10> Cars;

[0154] X is a previously defined entity type name, or a basic type, and Cars is a newly defined sequence entity type name. The first type is used to define variable-length arrays, and the second type is used for fixed-length arrays.

[0155] The first vector form in CDL: In C++, "vector <long>Years;" defines a vector variable Years, while in CDL "sequence <long>Years;", it just defines a vector data type Years with a member type of int. This Years is not a variable. For example, the following CDL structure declaration:

[0156]

[0157] In this declaration, Years is clearly used as an entity type name.

[0158] When this vector entity type description in CDL is converted into C++ code, the following statement is generated in the header file: typedef std::vector <int>Years;

[0159] The second vector form in CDL: Suppose there is the following statement in CDL: sequence<long,20> Years;

[0160] Then the corresponding C++ declaration is generated in the header file as follows: typedef int Years

[20] ;

[0161] After that, you can directly use the type name Years in the C++ code to define a variable of type int

[20] .

[0162] 4) Struct entity type mapping

[0163] The syntax of structure entity definition in CDL file is similar to C++, but not exactly the same. Here is an example to illustrate the structure entity mapping rule. The following is a CDL structure entity definition snippet:

[0164]

[0165] The mapping to C++ code is:

[0166]

[0167] The serialization and deserialization codes in the structure are used to support the communication between different components in a distributed environment. The serialization and deserialization here are implemented with the help of the boost library.

[0168] 5) Port entity type mapping

[0169] The port in CDL should be mapped to a class in C++. The general form of port definition in CDL is (the example does not contain the upper and lower bounds of the data value):

[0170] port port_type_name port_data_type;

[0171] Among them, port is a reserved word for port type declaration, port_type_name is the name of the port entity type being defined, and port_data_type is the data type associated with the port. port_data_type can be any of the basic data types given in Table 25-1, or a type name that has been defined before. A specific example is as follows:

[0172] port Sampling PostData;

[0173] Indicates that a port entity type called Sampling is defined, and the data type it publishes or subscribes to is the structure type PostData.

[0174] The port entity type is mapped to a class in C++, which is divided into two categories: publishing and subscribing, which are mainly distinguished by namespaces in C++.

[0175] 6) Interface entity type mapping

[0176] The interface in CDL should be mapped to a class in C++. The general form of the interface definition in CDL is (the example does not contain the upper and lower bounds of the data value):

[0177]

[0178] Among them, interface is a reserved word for interface entity type declaration, and interface_type_name is the name of the interface entity type being defined. The operation is a component of the component interface, and its form is like a function. Each operation can have one or more parameters and a return value. The types of parameters and return values ​​can be basic data types, enumeration types, structure types, etc., and void can also be used to indicate no return value. The parameters in the operation can have three transfer mode indicators: in, out, and inout:

[0179] The in indicator indicates that the parameter is an input parameter, that is, the parameter substituted into the operation is used by the business process of the operation, but the value of the substituted parameter cannot be changed. The const modifier should be added to the mapped C++ code to indicate that the parameter value cannot be changed.

[0180] The out indicator indicates that the corresponding parameter is an output parameter. The value of the parameter cannot be used during the business processing of the operation, but the result can be passed (output) to the caller through the parameter. It is mapped to a reference in the C++ code. Adding & before the parameter name means that the parameter reference can be changed.

[0181] The inout indicator indicates that the corresponding parameter is both an input parameter and an output parameter, that is, it has the characteristics of both input and output parameters. The mapping of C++ code is the same as the out indicator.

[0182] A specific example is as follows:

[0183]

[0184] In the code, IExample1 represents the interface type name, and the interface has two operations, Op1 and Op2.

[0185] The mapping to C++ code is mainly divided into two categories: external provision, external request and operation return value in the interface, and parameter serialization declaration, which are also distinguished by namespaces in C++.

[0186] 7) C++ code mapping of CDL component entities

[0187] According to the provisions of the CDL language, the core elements of a component are interfaces and ports. Interfaces are used to support remote method calls between components, and ports are used to support data interaction between components in a publish / subscribe manner. In addition, the interfaces in a component are divided into two different types: Provide and Require. The Provide interface (abbreviated as P-Interface) in a component is used to provide services to the outside world and can be called by other components or applications (remotely), while the Require interface (abbreviated as R-Interface) in a component indicates that the component needs to call the services provided by such an interface. The ports in a component are divided into two different types: Publish and Consume. The Publish port (abbreviated as P-Port) in a component is used to publish data to the outside world, while the Consume port (abbreviated as C-Port) is used to subscribe to and receive data published from the outside world.

[0188] Furthermore, the component entity is generated by compiling the C++ language component code framework, and the component entity is stored in a component directory included in the C++ language component code framework.

[0189] In an embodiment of the present invention,

[0190] The component directory can include the following three directories:

[0191] 1) Include directory

[0192] A C++ header file with the same name as the component description file to be compiled will be generated in the include directory. The C++ header file stores the C++ codes of the entities such as vectors, enumerations, structures, ports and interfaces declared in the component description file to be compiled after being converted using the mapping conversion rules.

[0193] 2) sources directory

[0194] A C++ source file with the same name as the component description file to be compiled will be generated in the sources directory. The C++ source file stores the implementation of the methods in the C++ class after the ports and interface entities declared in the component description file to be compiled are converted using the mapping conversion rules.

[0195] 3) Component directory

[0196] For each component defined in the component description file to be compiled, the component code generation software generates a subdirectory in the Component directory with the same name as the component. That is, if N components are defined in the component description file to be compiled, then there should be N subdirectories in the Component directory with the same names as the N components. All C++ codes after component entity mapping will be stored in the Component subdirectory by the component code generation software.

[0197] Each subdirectory with the same name as the component name generates two subdirectories: include subdirectory and sources subdirectory. In the include subdirectory, a C++ header file with the same name as the component name is generated, and the C++ header file stores the declaration of the C++ class after the component entity is mapped. In the sources subdirectory, a C++ source file with the same name as the component name is generated, and the implementation of the methods in the C++ class after the component entity is mapped is stored in the C++ source file.

[0198] A vs2010-based project file is stored in each component subdirectory to facilitate component implementers to fill in business code logic.

[0199] In the embodiment of the present invention, the C++ language component code framework is as follows: Figure 5 As shown in the figure, ComSer is a service component type, which is mapped to a class in C++ and must inherit the fixed Component class. The ComSer component provides an interface pInterface of type IExample1 to the outside world, and requests an interface rInterface of type IExample1; it publishes a port pPort of type Sampling to the outside world, and subscribes to a port cPort of type Sampling to the outside world.

[0200] pInterface is an inner class in the ComSer class. The pInterface class inherits the IExample1 class under the Provide namespace. The pInterface class implements the operations in the interface. The specific logic of the operation needs to be designed by the component implementer according to the requirements. Figure 5 The rInterface in the ComSer class is also an inner class in the ComSer class. The rInterface class inherits the IExample1 class under the Require namespace.

[0201] Figure 5 pPort is an inner class in ComSer class, which inherits Sampling class in Publsih namespace. cPort is also an inner class in ComSer class, which inherits Sampling class in Consume namespace. The specific logic of DataProcess function in this class needs to be designed by component implementers according to requirements.

[0202] In addition, the ComSer class is designed with a pointer to each internal class object instance. When the component implementer fills in the logic, external interface requests only need to call the Op1 or Op2 function in the rInterface class. External port publishing only needs to assign port data and then call the Publsih function in the pPort class.

[0203] The build entity is an information entity that contains the functions of the component code framework. The business codes filled in the component code framework can be called and used in the component entity. After the user fills in the business logic in the corresponding position in the component code framework, the code framework can be directly compiled in VS2010 to generate a component entity dll file. Each component will generate a corresponding dll. The component entity contains the specific implementation of the methods in the user's Provide interface. The specific business logic is written by the user, including the business logic for processing the results after requesting data in the Require interface, the logic of the Publish port for publishing data, and the business processing logic after the Consume receives data. At the same time, the underlying communication mechanism is encapsulated in it.

[0204] The component entity is no longer a code framework, but an information entity that can be called. In the Windows platform, the build entity is loaded through a dynamic link library, the component entity can be run, and the business written by the user in the component code framework can be called.

[0205] Based on the same inventive concept, an embodiment of the present invention provides an embedded component entity generation device. Since the principle of solving the technical problem of the device is similar to that of an embedded component entity generation method, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be repeated.

[0206] like Figure 6 As shown, the component entity generation device mainly includes a first generation unit 601 and a second generation unit 602.

[0207] The first generating unit 601 is used to obtain a compile instruction and a component description file to be compiled carried by the compile instruction, and generate an intermediate representation storing the component description file reduction according to the component description file to be compiled; wherein the component description file reduction records at least one element included in the component description file to be compiled and basic information of the element through a first keyword entity; the component description file to be compiled defines an ECOM component metamodel through elements;

[0208] The second generating unit 602 is used for the first keyword entity to generate a C++ language component code framework according to a framework mapping rule, compile the C++ language component code framework to generate a component entity, and store the component entity in a component directory included in the C++ language component code framework.

[0209] Preferably, the compile instruction further carries the compile switch, and the compile switch includes a first compile switch, a second compile switch and a third compile switch;

[0210] The first compile switch is used to set the storage path of the component description file to be compiled. When the first compile switch includes multiple ones, each of the first compile switches corresponds to a storage path of the component description file to be compiled;

[0211] The second compile switch is used to set a first output path of the C++ language component code framework, and before outputting the C++ language component code framework, the first output path needs to be scanned;

[0212] The third compilation switch is used to set a designated output path for the C++ language component code framework, and directly output the C++ language component code framework to the designated output path.

[0213] Preferably, the first generating unit 601 is specifically used for:

[0214] Reading characters included in the component description file to be compiled in sequence, analyzing the characters to obtain words corresponding to the characters, and arranging the words in rows to form a component description file without comments;

[0215] Among them, if the comment character / / is read in, all the words obtained by analyzing the characters after the comment character / / are empty until a newline character is read in; if the comment / * is read in, all the words obtained by analyzing the characters after the comment character / * are empty, and when a newline character is read in, the line number corresponding to the newline character is written as "+1" until the comment character * / is read in.

[0216] Preferably, the first generating unit 601 is specifically used for:

[0217] Scan the unannotated component description file line by line, and when the first word read in matches an element, add the first word and basic information of the first word to a first keyword entity corresponding to the element; add a pointer to the first keyword entity to a component description file reduction corresponding to the unannotated component description file, and add a definition of the first keyword entity in the component description file reduction;

[0218] If the read second word does not match the element name, generating a first keyword entity according to the second word and adding it to the component description file for reduction;

[0219] Among them, the elements include at least: component, interface, port, enumeration, structure, union; the first keyword entity includes at least: component entity, interface entity, port entity, enumeration entity, structure entity, union entity.

[0220] Preferably, the C++ language component code framework includes an include directory, a sources directory and a component directory;

[0221] The include directory generates a C++ header file with the same name as the component description file to be compiled;

[0222] The sources directory generates a C++ source file with the same name as the component description file to be compiled;

[0223] The component directory generates a subdirectory that is consistent with the name of the component description file to be compiled, and the subdirectory is used to store the component entity corresponding to the name of the component description file to be compiled.

[0224] It should be understood that the units included in the above embedded component entity generation device are only logical divisions based on the functions implemented by the device. In actual applications, the above units can be superimposed or split. In addition, the functions implemented by the embedded component entity generation device provided in this embodiment correspond to the embedded component entity generation method provided in the above embodiment. The more detailed processing flow implemented by the device has been described in detail in the above method embodiment 1 and will not be described in detail here.

[0225] Although the preferred embodiments of the present invention have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0226] Obviously, those skilled in the art can make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if these modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include these modifications and variations.< / int> < / long> < / long> < / x>

Claims

1. A method for generating an embedded component entity, characterized in that: include: Obtaining a compile instruction and a component description file to be compiled carried by the compile instruction, and generating an intermediate representation storing the component description file reduction according to the component description file to be compiled; wherein the component description file reduction records at least one element included in the component description file to be compiled and basic information of the element through a first keyword entity; the component description file to be compiled defines an ECOM component metamodel through elements; The first keyword entity generates a C++ language component code framework according to a framework mapping rule, and the C++ language component code framework is compiled to generate a component entity; the component entity is stored in a component directory included in the C++ language component code framework; The step of generating an intermediate representation in memory according to the component description file to be compiled specifically includes: Reading characters included in the component description file to be compiled in sequence, analyzing the characters to obtain words corresponding to the characters, and arranging the words in rows to form a component description file without comments; If the comment character / / is read, all the characters after the comment character / / are analyzed to be empty, until a newline character is read; if the comment character / * is read, all the characters after the comment character / * are analyzed to be empty, and when a newline character is read, the line number corresponding to the newline character is written as "+1", until the comment character * / is read; Scan the unannotated component description file line by line, and when the first word read in matches an element, add the first word and basic information of the first word to a first keyword entity corresponding to the element; add a pointer to the first keyword entity to a component description file reduction corresponding to the unannotated component description file, and add a definition of the first keyword entity in the component description file reduction; If the read second word does not match the element name, generating a first keyword entity according to the second word and adding it to the component description file for reduction; Among them, the elements include at least: component, interface, port, enumeration, structure, union; the first keyword entity includes at least: component entity, interface entity, port entity, enumeration entity, structure entity, union entity.

2. The generation method according to claim 1, characterized in that: The compile instruction also carries the compile switch, which includes a first compile switch, a second compile switch and a third compile switch; The first compile switch is used to set the storage path of the component description file to be compiled. When the first compile switch includes multiple ones, each of the first compile switches corresponds to a storage path of the component description file to be compiled; The second compile switch is used to set a first output path of the C++ language component code framework, and before outputting the C++ language component code framework, the first output path needs to be scanned; The third compilation switch is used to set a designated output path for the C++ language component code framework, and directly output the C++ language component code framework to the designated output path.

3. The generation method according to claim 1, characterized in that: The framework mapping rules include any one or more combinations of the following: Basic data type mapping, enumeration entity type mapping, sequence entity type mapping, structure entity type mapping, port entity type mapping, interface entity type mapping, component entity type mapping.

4. The generation method according to claim 1, characterized in that: The ECOM component meta-model at least includes a component, and the component includes N component parameters, N component attributes, N interfaces and N ports, wherein N is a natural number.

5. The generation method according to claim 1, characterized in that: The C++ language component code framework includes an include directory, a sources directory and a component directory; The include directory generates a C++ header file with the same name as the component description file to be compiled; The sources directory generates a C++ source file with the same name as the component description file to be compiled; The component directory generates a subdirectory that is consistent with the name of the component description file to be compiled, and the subdirectory is used to store the component entity corresponding to the name of the component description file to be compiled.

6. An embedded component entity generation device, characterized in that: include: A first generating unit is used to obtain a compile instruction and a component description file to be compiled carried by the compile instruction, and generate an intermediate representation storing a reduction of the component description file according to the component description file to be compiled; wherein the component description file reduction records at least one element included in the component description file to be compiled and basic information of the element through a first keyword entity; the component description file to be compiled defines an ECOM component metamodel through elements; A second generating unit is used for generating a C++ language component code framework from the first keyword entity according to a framework mapping rule, compiling the C++ language component code framework to generate a component entity; and storing the component entity in a component directory included in the C++ language component code framework; The first generating unit is specifically used to: sequentially read characters included in the component description file to be compiled, analyze the characters to obtain words corresponding to the characters, and arrange the words in rows to form a component description file without comments; If the comment character / / is read, all the characters after the comment character / / are analyzed to be empty, until a newline character is read; if the comment character / * is read, all the characters after the comment character / * are analyzed to be empty, and when a newline character is read, the line number corresponding to the newline character is written as "+1", until the comment character * / is read; Scan the unannotated component description file line by line, and when the first word read in matches an element, add the first word and basic information of the first word to a first keyword entity corresponding to the element; add a pointer to the first keyword entity to a component description file reduction corresponding to the unannotated component description file, and add a definition of the first keyword entity in the component description file reduction; If the read second word does not match the element name, generating a first keyword entity according to the second word and adding it to the component description file for reduction; Among them, the elements include at least: component, interface, port, enumeration, structure, union; the first keyword entity includes at least: component entity, interface entity, port entity, enumeration entity, structure entity, union entity.

7. The generating device according to claim 6, characterized in that The compile instruction also carries the compile switch, which includes a first compile switch, a second compile switch and a third compile switch; The first compile switch is used to set the storage path of the component description file to be compiled. When the first compile switch includes multiple ones, each of the first compile switches corresponds to a storage path of the component description file to be compiled; The second compile switch is used to set a first output path of the C++ language component code framework, and before outputting the C++ language component code framework, the first output path needs to be scanned; The third compilation switch is used to set a designated output path for the C++ language component code framework, and directly output the C++ language component code framework to the designated output path.

Images