KR20050051234A - Software package descripter file architecture in sca system and file parsing method thereof - Google Patents

Abstract

The present invention relates to a software package descriptor file structure and a file parsing method thereof in an SCA based system.

In the present invention, the SCA-based system has information about the component, the component is a software package descriptor file structure having one or more dependent components, the information defining unit for defining the software package related information for the component; And implementation information including property files, implementation code information, and hardware / software dependencies for the component. The implementation unit includes deployment-related information for all dependent components that are dependent on the component.

According to the present invention, a plurality of component-related information having a dependency relationship is described in one software package descriptor file, thereby minimizing the number of software package descriptor files, thereby facilitating file management.

Description

Software package descriptor file architecture in SCA based system and its file parsing method

The present invention relates to a software communication architecture (SCA) based system, and more particularly, to a software package descriptor file structure of an SCA based system and a file parsing method thereof.

In the Joint Tactical Radio System (JTRS) Joint Program Office (JPOS), which was established to develop future communication systems using technology that has been developed until recently, SCA aims to significantly improve interoperability between communication systems and reduce development and deployment costs. It is the proposed communication software structure. SCA adopts the common object request broker architecture (CORBA), the industry standard for distributed object models, as a middleware to provide an integrated environment of heterogeneous hardware and software. This is not a specification specific to a particular system, but an independent system design framework. SCA-based system refers to a communication system based on this SCA structure. For example, SDR (Software Defined Radio) systems adopt SCA as a standard for software frameworks.

In addition, the SCA describes information on hardware and software components as a domain profile by applying eXtensible Markup Language (XML) Document Type Definition (DTD).

The domain profile consists of descriptor files for describing the hardware and software configuration information of the system, among which the software package descriptor file includes information related to component implementation for use in placing the component at a specific device location. . The software package descriptor file including the implementation information may include another software package descriptor file that defines a component in the form of a library to be loaded in advance before loading or executing the corresponding component. A dependent software package descriptor file that defines component implementation information in the form of a library having such dependent elements generally has attributes defined in a software package descriptor file (main software package descriptor file) containing such a file.

Therefore, when the dependent software package descriptor file is implemented as a separate file and the same attributes as those defined in the main software package descriptor file are managed by redefining the dependent software package descriptor file in addition to the attributes of the main software package descriptor file, By parsing the attributes of the dependent package descriptor file as well, unnecessary parsing of the same attributes is performed continuously, resulting in overall performance degradation. In addition, the number and size of domain profiles are inefficiently used.

Therefore, the technical problem to be achieved by the present invention is to reduce the number of total software package descriptor files and the total domain profile size by managing the software package descriptor file describing the software package information of component units in an SCA-based system with an efficient structure. will be.

Another object of the present invention is to provide a method for shortening the parsing time of a software package descriptor file.

In order to achieve the above technical problem, the software package descriptor file structure according to an aspect of the present invention has information about a component in an SCA-based system, and the component includes a software package descriptor file having one or more dependent components. An information defining unit defining software package related information about the component; And implementation information including property files, implementation code information, and hardware / software dependencies for the component. The implementation unit includes deployment-related information for all dependent components that are dependent on the component.

The information definition unit may include a property file module providing an absolute path to a property descriptor file associated with the software package; An author module defining a developer who created the component; A description module for defining descriptive information about the component; A title module defining a title for displaying the component; A using device module for indicating that the component is related to a device in an SCA based system; And a descriptor module that defines a software component descriptor related file name describing information about an interface provided or used by the component.

The implementation unit may include a property module defining a real-time environment for the component implementation and describing property information including an associated compiler and a language type; A using device module for indicating that the component is related to a device in an SCA based system; An implementation group module for describing the operating system or processor in which the component is implemented and used, and component information depending on the component; And a code module displaying a code file name and an execution start position of the software component of the software component.

The feature module comprises: a description module defining information set by the software developer for the component implementation; A property file module providing an absolute path to the property descriptor file; A real time module defining a real time environment required for implementing the component; A compiler module for displaying a compiler used in association with the software component; A language module for indicating a programming language type used for the software component; And a human language module for indicating the type of human language used in association with the software component.

The implementation group module may include an operating system module indicating an operating system on which the software component will operate; A processor module indicating a processor on which the software component will operate; And a subordinate module for displaying a subordinate relationship between the component and the subordinate component.

Meanwhile, the dependent module defines a dependency relationship property type for the component and the dependent component. In particular, the dependent module may include a property reference module that displays an identifier for each property type defined for checking a dependency relationship with the dependent component and a value of the corresponding identifier; It includes an implementation set that defines the placement-related information for the dependent component.

The implementation aggregation unit may include: an information definition unit defining software package related information about the dependent component; And implementation information including property files, implementation code information, and hardware / software dependencies for the dependent components, including implementation-related information for all the dependent components that are dependent on the dependent component.

The implementation aggregation unit includes a first implementation aggregation unit including the dependent module; And a second implementation aggregation unit that does not include the dependent module.

A file parsing method according to another aspect of the present invention is a method of parsing a software package descriptor file having information on a component in an SCA-based system, wherein the component has one or more dependent components, a) the software package descriptor Reading the file and storing the content of the file in an internal variable, checking the total number of components among the stored contents, and storing the content in the internal variable; b) if a component exists in the file, and if there is an information definition module describing the first information including the software package related name and the author for the component, parsing the information definition module and storing it in an internal variable. ; c) if the information definition module does not exist, if there is an implementation module comprising a plurality of modules describing second information including property files, implementation code information and hardware / software dependencies for the component, the implementation Parsing each module included in the module and storing the module in an internal variable; d) checking whether there is a dependent module in the implementation module including deployment related information for all dependent components that are dependent with the component; And e) parsing dependent component information by parsing a plurality of modules constituting the dependent module when the dependent module exists.

Here, the step e) may include parsing the characteristic reference module and storing it in an internal variable when the characteristic reference module exists in the dependent module when the dependent module exists; And parsing an implementation collection unit that defines placement-related information for components having a dependency relationship existing in the dependent module and storing the parsing unit in an internal variable.

Step e) performs steps a) to d) on the dependent component to parse corresponding information.

In addition, a recording medium according to another aspect of the present invention has information about a component in an SCA-based system, the component defining a software package related information for the component in a recording medium having one or more dependent components. An information definition unit; And implementation information including property files, implementation code information, and hardware / software dependencies for the component, wherein the computer has data having an implementation including deployment related information for all dependent components that are dependent on the component. Readable recording medium.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those skilled in the art may easily implement the present invention. As those skilled in the art would realize, the described embodiments may be modified in various different ways, all without departing from the spirit or scope of the present invention.

In the present invention, in order to maximize portability and reuse of domain-specific or intra-domain software in an SCA-based system, a component that can be deployed and replaced (in this case, a component means a component that constitutes software that can be deployed and replaced) Efficiently manages the dependency structure among the XML DTD structure of the software package descriptor that describes the software package related name, author, properties file, implementation code information, and hardware / software dependencies. In addition, the present invention provides a method for reducing the number of total software package descriptor files and the size of a domain profile and reducing the time for parsing the files.

1 shows the general structure of an SCA-based system.

As shown in (a) of FIG. 1, an SCA-based system includes a plurality of components, that is, one device manager 101 managing a device, a plurality of logical devices 102 functionally abstracting a hardware device, logs, and events. It may include a plurality of services 103 for processing a plurality of XML data 104 describing hardware and software information, and a plurality of libraries 105 configured in a library form to support components.

In contrast, as shown in FIG. 1B, the SCA-based system processes one device manager 111 managing a device, a plurality of logical devices 112 functionally abstracting a hardware device, logs, and events. A plurality of services 113, a plurality of XML data 114 describing hardware and software information, a plurality of libraries 115 configured to support each component in the form of a library, a plurality of applications for software control and configuration 116, a domain manager 117, one file manager 118 that manages the file system, and a plurality of XML parsers 119 that parse XML data.

As illustrated in FIG. 1, a domain profile describing configuration information of an SCA-based system that may be configured with respective hardware and software components has a structure as follows. 2 is a schematic structural diagram of a domain profile.

As shown in FIG. 2, the domain profile 10 includes a device configuration descriptor 11, a domain manager configuration descriptor 12, a software assembly descriptor 13, a software package descriptor 14, and a software component descriptor 15. It includes.

In addition, a property descriptor including a property to be applied to a software / hardware component, a profile descriptor providing an absolute file path for the components 11 to 14, and a device package descriptor including hardware configuration related property information about the device are additionally added. It may also include.

The device configuration descriptor 11 describes how to initially describe the component to run on the node where the device manager is located, how to obtain a domain manager, how to connect a service to the component, and features (such as file system names) for the device manager. A file that provides a means to describe. This file may not exist in the domain profile or may exist in multiple instances.

The domain manager configuration descriptor 12 is a file that provides configuration information about the domain manager and a means for describing a service to be used, and there may be only one in the domain profile.

Software assembly descriptor 13 is a file that provides a means of describing the aggregated functional applications and the interconnect characteristics of the components within those applications, and may or may not exist in a domain profile.

The software component descriptor 15 is a file that provides a means of describing information about an interface provided and / or used by a particular software component, and there is only one for each of the software package descriptors 24 in a domain profile. It may not.

Software package descriptor 14 is a file that provides a means of describing information such as software package related name, author, properties file, implementation code information, hardware / software dependencies, etc. to identify a software component implementation. May exist.

In the SCA-based system as described above, if the software package descriptor 14 including the component implementation related information is used for the purpose of locating the component at a specific device location while configuring the domain profile, That is, in the case of having a dependency element that defines another component in the form of a library to be preloaded before loading or executing the corresponding component, the software package descriptor 14 conventionally defines a component having a dependency relationship in the form of a separate file. You must include any dependent software package descriptors that exist. That is, the number of dependent software package descriptor files exists as many as the number of all components including the component having a dependency relationship.

3 illustrates a structure for explaining a software package descriptor file relationship according to an embodiment of the present invention. Specifically, FIG. 3A illustrates a software package descriptor file relationship according to the prior art, and FIG. 3B illustrates a software package descriptor file relationship according to an embodiment of the present invention.

For example, if the software package descriptor 14 file has three dependent components, conventionally the software package descriptor 14 file has three dependent software package descriptors 14A and 14B as shown in FIG. , 14C) file. Also, if the dependent software package descriptor 14A file has two dependent components, the dependent software package descriptor 14A file includes two dependent software package descriptor 14A1, 14A2 files.

However, in the embodiment of the present invention, as shown in FIG. 3 (b), only one software package descriptor 14 (hereinafter, for convenience of description) is described in order to describe the predetermined component and the component placement related information having a dependency thereon. The file number is " 1 "

In addition, in the related art, since the dependent software package descriptor file is included, the software package reference module for describing the dependent component, the file reference located in the software package reference module and displaying the dependent software package descriptor file describing the dependent component in the form of a library, are referred to. Modules, such as specific implementation reference modules to identify specific implementation modules within the dependent software package descriptor file, are additionally needed, while in the present invention such modules are not required, the structure of the software package descriptor file may be more simply implemented. Can be.

To this end, the soft package descriptor file according to an embodiment of the present invention has the following structure.

4 illustrates a structure of a software package descriptor file (hereinafter, referred to as a software package descriptor) according to an embodiment of the present invention.

The software package descriptor 1 according to an embodiment of the present invention includes an implementation module 11 and an information definition module 12 defining characteristics of a component.

The information definition module 12 is largely a property file module 121, an author module 122, and a description module 123. A title module 124, a use device module 125, and a descriptor module 126.

The property file module 121 is a module that provides an absolute path to a property descriptor file associated with a software package. The property file module 121 may not exist, and only one exists if present.

Author module 122 is a module that defines the developer who created the component, there is one or more, the description module 123 is a module that defines the descriptive information about the component. This description module 123 may not exist, and only one exists if present.

The title module 124 is a module that defines a title for displaying a component. The title module 124 may not exist or only one exists if present.

The use device module 125 is a module indicating that a component is related to a device in an SCA-based system. The device module 125 may not exist or only one exists if present.

The descriptor module 126 is a module used to define a related file name used in the software component descriptor 1 of the domain profile shown in FIG. This module may not exist, or only one exists if present.

On the other hand, the implementation module 11 includes descriptive information about a special implementation template for a software component. It also defines implementation-dependent dependency properties for device / application creation and supports different types of processors / operating systems on the same component. One or more such implementation modules 11 exist in one software package descriptor.

The implementation module 11 having this characteristic is largely described as a module 1111. A property module 111 including the property file module 1112, a real time module 1114, a compiler module 1115, a language module 1113, a human language module 1116, an implementation group module 112, a code module ( 113) and use device module 114.

The description module 1111 is a module in which a software developer defines descriptive information about a component implementation. The description module 1111 may not exist or, if present, only one.

The property file module 1112 is a module that provides an absolute path to a property descriptor file associated with a software package implemented in the implementation module 111. The property file module 1112 may not exist or only 1 exists.

The language module 1113 is a module used to indicate a programming language type used in connection with a software component. The language module 1113 may not exist, and only one exists.

The real-time module 1114 is a module used to define a real-time environment required for implementing a component. The real-time module 1114 may not exist or only one exists if present.

The compiler module 1115 is a module used to indicate a compiler used in association with a software component. The compiler module 1115 may not exist, and only one exists.

The human language module 1116 is a module used to indicate the type of human language used in connection with a software component, which may or may not exist and there is only one.

Like the use device module 114, the use device module 114 is a module for indicating that a component is related to any device in an SCA-based system. The use device module 114 may not exist, and only one exists.

The code module 113 specifically includes an entry point module 1131, a stack size module 1132, a priority module 1133, and a file reference module 1134 to support the above functions.

The entry point module 1131 is optionally an execution point of execution code, a stack size module 1132 is a stack size, and a priority module 1133 is a module used to indicate execution priority, if necessary. The modules 1131 to 1133 can be implemented as one module, and only one may exist but may not exist.

There is only one file reference module 1134 as a module used to indicate the code file name of a software component described for a particular implementation.

On the other hand, the implementation group module 112 is a module used to describe the operating system or processor that the component is implemented and used, and the component information in a dependency relationship. This implementation group module 112 is largely comprised of an operating system module 1121, a processor module 1122, and a dependent module 1123.

Operating system module 1121 is a module used to indicate an operating system on which a software component will operate, and a processor module 1122 is a module used to indicate a processor on which a software component will operate. One or more such operating system module 1121 and processor module 1122 exist within implementation group module 112.

The dependency module 1123 is a module used to indicate a dependency relationship between a component and another component, and is used to define a characteristic type of a dependency relationship or to define a dependent component in a library form.

The dependent module 1123 according to the embodiment of the present invention specifically includes a property reference module 11231 and a dependent component implementation aggregation unit 11232.

The property reference module 11231 is a module used to display a property type-specific identifier and a value of the corresponding identifier defined in the package to check dependency. There is only one.

The dependent component implementation set unit 11232 defines a component having a dependency relationship with the software package descriptor 1 and records deployment related information, and includes all the modules 11 and 12 described above.

There may be a plurality of such dependent component implementation setters 11232 according to the number of components having a dependency relationship, and one dependent component implementation setter 11232 may be dependent on a dependent module ( Sub-dependent module). The dependent component implementation aggregation unit 1232 may be classified into a first implementation aggregation unit having a dependency module for a component having a dependency relationship, and a second implementation aggregation unit having no dependency module because there is no component having a dependency relationship.

5 illustrates a connection relationship between dependent modules according to dependency of components according to an exemplary embodiment of the present invention.

That is, when there is a first component having a dependency relationship with the software package descriptor 1, and there is a second component having a dependency relationship with the first component, as shown in FIG. 5, the dependent module of the software package descriptor 1 ( 1123 has a first dependent component implementation aggregation unit B1, B2 for the first component. The first dependent component implementation aggregation unit may include a first implementation aggregation unit B1 having no dependent module and a second implementation aggregation unit B2 having the dependency module 1123B2 for the second component. The dependent module 1123B2 of the second implementation aggregation unit B2 includes a second dependent component implementation C1 for the second component. Here, although only two components having a dependency relationship are illustrated, even when two or more stepwise dependency relationships are formed, as described above, the dependent component implementation having one or more substeps in the dependent module may be implemented.

As described above, in the exemplary embodiment of the present invention, two or more components having a dependency relationship may be represented in one software package descriptor file 1.

Next, as described above, a parsing process of the software package descriptor 1 having information on a component having a dependency in an SCA-based system will be described.

6 is a flowchart illustrating a parsing process of a software package descriptor file according to an embodiment of the present invention. This process is performed in the device (execution device) using the soft package descriptor file, and all processes are mainly performed by the execution device.

For example, in order to parse the contents by reading the software package descriptor (1) file from a file system in which a large number of files are stored, the contents of the file are stored in an internal variable, and the total number of stored components is checked first. Store in an internal variable. Next, as shown in Fig. 6, if the component exists, it is checked whether the information definition module 12, that is, the property file / descriptor file / author / description / title / use device modules 121 to 126 exists ( S100).

If the information definition module 12 exists, each module 121 to 126 constituting the information definition module 12 is parsed and stored in an internal variable. If the information definition module 12 does not exist, the implementation module ( 11) check whether there exists (S200 ~ S300).

In step S300, if the implementation module 11 exists, the description / characteristic file / real time / compiler / language / human language / implementation group / code / use device module 1111 which is a module constituting the implementation module 11. 1116 and 112-114 are parsed, and the operating system / processor modules 1121 and 1122 in the implementation group module 112 are parsed and stored in internal variables (S400).

Next, it is checked whether the dependent module exists in the implementation module 11 (S500), and if the dependent module 1123 does not exist, the parsing process is terminated (S600).

However, if the dependent module 1123 exists in step S500, it is checked whether the characteristic reference module 11231 exists in the dependent module 1123. If the characteristic reference module 11231 exists, the characteristic reference module is parsed and stored in an internal variable (S700).

On the other hand, if there is a dependent component implementation setr 11232 for another dependent component having a dependency in the dependent module 1123, the process transitions to parsing information on the dependent component and parses component information having a dependency relationship. do. The step for parsing the information on the dependent component is the same as the above-described steps (S100 to S700). This parsing process is optionally performed depending on the presence of the dependent module 1123 for the dependent component.

Although the preferred embodiments of the present invention have been described in detail above, the scope of the present invention is not limited thereto, and various modifications and improvements of those skilled in the art using the basic concepts of the present invention defined in the following claims are also provided. It belongs to the scope of rights.

According to this embodiment of the present invention, the software package descriptor file can be managed in an efficient structure in the SCA-based system.

In particular, a plurality of component-related information having a dependency relationship is described in one software package descriptor file, thereby minimizing the number of software package descriptor files, thereby facilitating file management.

In addition, since information about dependent components is described together in one software package descriptor file, there is no need for a module for describing a reference relationship and an implementation relationship with the dependent software package descriptor file for the dependent component. As a result, module configuration can be simplified by removing unnecessary modules. In addition, the size of the software package descriptor file of the domain profile that defines the component can be reduced.

In addition, even when a plurality of dependent components exist for one component, only one software package descriptor file is read and systematically parsed to confirm information on all components, thereby reducing the time for parsing the file.

1 is a general structural diagram of an SCA-based system.

2 is a schematic structural diagram of a domain profile.

3 is an exemplary diagram for describing a software package descriptor file relationship according to an embodiment of the present invention.

4 is a structural diagram of a software package descriptor file according to an embodiment of the present invention.

5 is a flowchart illustrating a parsing process of a software package descriptor file according to an embodiment of the present invention.

Claims (14)

In a software communication architecture (SCA) based system, the component has information about a component, and the component has a software package descriptor file structure having one or more dependent components. An information defining unit defining software package related information about the component; And An implementation unit that describes implementation information including property files, implementation code information, and hardware / software dependencies for the component, and includes deployment related information for all dependent components that are dependent on the component. Software package descriptor file structure comprising a. The method of claim 1, The information defining unit A property file module providing an absolute path to a property descriptor file associated with the software package; An author module defining a developer who created the component; A description module for defining descriptive information about the component; A title module defining a title for displaying the component; A using device module for indicating that the component is related to a device in an SCA based system; And Descriptor module defining a file name related to a software component descriptor describing information about an interface provided or used by the component. A software package descriptor file structure that includes at least one of the following. The method of claim 1, The implementation unit A characteristic module defining a real-time environment for the component implementation and describing characteristic information including an associated compiler and type of language used; A usage device module indicating that the component is related to a device in an SCA based system; An implementation group module for describing the operating system or processor in which the component is implemented and used, and component information depending on the component; And Code module for displaying the code file name and execution start position of the software component of the software component A software package descriptor file structure that includes at least one of the following. The method of claim 3, The characteristic module A description module for defining information set by the software developer for the component implementation; A property file module providing an absolute path to the property descriptor file; A real time module defining a real time environment required for implementing the component; A compiler module for displaying a compiler used in association with the software component; A language module for indicating a programming language type used for the software component; And Human language module for displaying the type of human language used for the software component Software package descriptor file structure that includes. The method of claim 3, The implementation group module, An operating system module indicating an operating system on which the software component will operate; A processor module indicating a processor on which the software component will operate; And Subordinate module that displays the subordinate relationship between the component and the dependent component Software package descriptor file structure that includes. The method of claim 5, The dependent module is a software package descriptor file structure defining a dependency relationship property type for the component and the dependent component. The method of claim 5 The dependent module A property reference module displaying an identifier for each property type defined for checking a dependency relationship with the dependent component and a value of the corresponding identifier; Implementation set unit defining the layout-related information for the dependent component Software package descriptor file structure comprising a. The method of claim 7, The implementation aggregation unit An information defining unit defining software package related information about the dependent component; And An implementation unit that describes implementation information including a property file, implementation code information, and hardware / software dependency on the dependent component, and includes implementation-related information about all dependent components that are dependent on the dependent component. Software package descriptor file structure comprising a. The method of claim 8 The implementation aggregation unit A first implementation aggregation unit including the dependent module; And Second implementation aggregation unit that does not include the dependent module A software package descriptor file structure that includes at least one of the following. The method of claim 3, The code module, An entry point module that displays an execution point of execution code; A stack size module for displaying a stack size; A priority module for displaying execution priority; File reference module indicating the code file name of the described software component for the configured implementation A software package descriptor file structure that includes at least one of the following. In a method for parsing a software package descriptor file having information about a component in an SCA-based system, the component having one or more dependent components, a) reading the software package descriptor file and storing the contents of the file in an internal variable, checking the total number of components among the stored contents, and storing the contents in the internal variable; b) if a component exists in the file, and if there is an information definition module describing the first information including the software package related name and the author for the component, parsing the information definition module and storing it in an internal variable. ; c) if the information definition module does not exist, if there is an implementation module comprising a plurality of modules describing second information including property files, implementation code information and hardware / software dependencies for the component, the implementation Parsing each module included in the module and storing the module in an internal variable; And d) checking whether there is a dependent module in the implementation module including deployment related information for all dependent components that are dependent with the component; And e) parsing dependent component information by parsing a plurality of modules constituting the dependent module, if the dependent module exists; File parsing method The method of claim 11, Step e) Parsing the characteristic reference module and storing it in an internal variable if the characteristic reference module exists in the dependent module when the dependent module exists; And Parsing an implementation collection unit that defines deployment-related information on components having dependency relationships existing in the dependent module and storing them in internal variables File parsing method The method of claim 11, Step e) And parsing the corresponding information by performing steps a) to d) on the dependent component. In an SCA-based system, a component has information about a component, and the component is in a recording medium having one or more dependent components. An information defining unit defining software package related information about the component; And An implementation unit that describes implementation information including property files, implementation code information, and hardware / software dependencies for the component, and includes deployment related information for all dependent components that are dependent on the component. The computer-readable recording medium having the data recorded thereon.