JP2007012003A - System for providing development environment of feature-oriented software product line - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a development environment system for feature-oriented software reuse, supporting methodology of feature-oriented software product line engineering. <P>SOLUTION: This system includes: an ASADAL/FORM 100 selecting a feature corresponding to an application program from features generated by feature modeling to a specific area; an ASADAL/COMP 200 developing an asset component on the basis of feature selection information, and performing generation of a software component through macro processing and shape management of the software component; an ASADAL/OBJ 300 performing architecture modeling and operation modeling for developing the application software, automatic code generation, construction of a virtual test bed, and verification through simulation; an ASADAL/ASSET DB 400 storing data generated by them; and an ASADAL/ANALYZER 500 verifying consistency between the data stored therein. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to a development environment for a feature-oriented software product line, and more particularly, to a feature analysis and application to a domain by applying a software product line methodology to a specific domain (or region). Feature selection for program development, generation of reusable asset components, generation of software components through macro processing and shape management for components, development of application software using software components and software testing in virtual environments The present invention relates to a system embodying a development environment for a feature-oriented software product line that facilitates development of a software product line.

  In recent years, the focus of software reuse technology to improve software development productivity has been from source code reuse to software design reuse, and again from software design reuse to domain engineering-based reuse. The center has moved. The reason why software reuse technology has changed in this way is that design reuse must be preceded in order to reuse source code, and in order to reuse design, it is common in the applicable application areas through domain engineering. This is because the territory assets to be used have to be developed first. For this reason, research on software reuse has been focused on domain analysis and domain engineering in recent years.

  A domain engineering approach in research on software reuse technology is to analyze a wide range of applicable application areas and thereby develop highly reusable components. However, in many cases, such access methods tend to include all products in the domain, which causes a problem of increasing software development cost and time. Further, as an effort to maximize the software reusability, emphasizing the hierarchization of the software structure and the encapsulation for concealing information has a problem that the performance of the system is lowered as a result. As described above, it is a difficult problem to determine an appropriate area range and a degree of reusability when software is reused mainly in a corresponding application area.

  To solve some of the problems described above, a software product line engineering paradigm has been presented. According to this paradigm, software reuse is done under a carefully planned plan to reuse specific software product lines. In other words, according to software product line engineering, based on the results of analyzing the market situation that companies are going to enter, the scope of area analysis and the development scope of software product line assets based on this must be clarified. Can do.

  Software product line engineering is a commonality and difference between software that provides consistent functions targeted at one or more markets to develop the core software assets of the software product line. (variability) is analyzed and a strategy for developing reusable components and software architectures that accept changes based on this is presented. Recently, interest and recognition in software product line engineering for the strategic reuse of such software has gradually increased, and research on this has been actively conducted.

  However, systematic and supporting the overall methodology of software product line engineering, such as analyzing commonalities and differences for domains, developing flexible software architecture and reusable components according to such software product line engineering concepts No system has yet been proposed that provides an effective software development environment.

  Therefore, the present invention has been made in view of the above circumstances, and the object of the present invention is asadal (A System Analysis and Design Aided tool: hereinafter referred to as “ASADAL”) that supports a methodology of feature-oriented software product line engineering. Provide a development environment system for feature-oriented software reuse that supports the methodology of the software product line by defining the framework and defining the structure of each module, the function of the module, and the flow of data. There is to do.

  Further, the present invention uses such a systematic development environment to obtain a reusable software asset based on the result of feature modeling in which common points and differences are analyzed with respect to the domain. The purpose is to develop high-quality software based on the concept of software product line engineering by developing application software efficiently by using and testing it based on 3D simulation .

  In order to achieve the above object, a system for providing a development environment for a feature-oriented software product line according to the present invention selects a feature corresponding to an application program from among feature modeling for a specific region and the features generated by the feature modeling. ASADAL / FORM that develops an asset component based on the feature selection information, generates a software component through macro processing, and manages the shape of the software component, and an architecture for developing the application software ASADAL / OBJ for performing modeling and operation modeling and automatic code generation, virtual testbed construction and verification through simulation, and the above-mentioned ASADAL / FORM, ASADA It includes an ASADAL / ASET DB that stores data generated by L / COMP and ASADAL / OBJ, and an ASADAL / ANALYZER that verifies the consistency between the data stored in the ASADAL / ASSE DB. .

  In accordance with the present invention, ASADAL, a system that provides a development environment for feature-oriented software reuse, has functional, environmental, technical, and implementation commonalities and differences between systems in a similar system domain. By clearly analyzing and reflecting this in component development, there is an advantage of improving the reusability and adaptability of components.

  Further, in the development environment according to the present invention, it is possible to verify a model from the initial stage of software development and find a model error by simulation. Accordingly, the reliability of the model can be increased by such an analysis, and a serious error can be inspected at the early stage of software development, so that the development cost can be greatly reduced.

  In the software inspection through the three-dimensional simulation according to the present invention, an environment that is actually similar to the real world is constructed by three-dimensional modeling, and software inspection and evaluation are performed based on the environment, so that various inspections can be performed at low cost. There is an advantage that you can. In particular, since real-time control systems are mostly embedded systems, it is not possible to inspect and evaluate whether the external hardware environment and the internal software system normally interact with each other. Not only can the reliability of the software be improved, but the inspection cost of the system can be greatly reduced.

  The development environment according to the present invention provides a systematic framework that supports all stages of software analysis, design, implementation, and testing, so that a meaningful product can be obtained at each stage. There is. In addition, the development environment according to the present invention is designed to enable efficient reuse of software, and such a reuse technique can be widely applied to the development of software in various fields.

DESCRIPTION OF EXEMPLARY EMBODIMENTS Hereinafter, preferred embodiments of the invention will be described with reference to the accompanying drawings.
FIG. 1 is a block diagram showing the configuration of the ASADAL framework, which is a development environment for a feature-oriented software product line according to the present invention. The system according to the present invention includes five components, ASADAL / FORM100, ASADAL / COMP200, ASADAL / OBJ300, ASADAL / ASSE DB400, and ASADAL / ANALYZER500. Among the components of the system shown in FIG. 1, ASADAL / FORM100, ASADAL / COMP200, ASADAL / OBJ300, and ASADAL / ANALYZER500 are embodied in software that can be executed by one computer or a plurality of computers connected by a network. Can be done.

  In the system according to the present invention, the ASADAL / FORM 100 performs a function modeling for a region and a function of selecting a feature corresponding to an application program, and the ASADAL / COMP 200 generates a software component and develops a component shape through asset component development and macro processing. Perform management functions. The ASADAL / OBJ300 provides an architecture modeling and operation modeling and automatic code generation for developing application software, a virtual testbed construction and a verification function through simulation. The ASADAL / ASSE DB 400 stores the products generated by the modules described above, and the ASADAL / ANALYZER 500 verifies the consistency among the products stored in the ASADAL / ASSE DB 400.

Hereinafter, each module constituting ASADAL, which is a system for providing a development framework according to the present invention, will be described in detail with reference to the accompanying drawings.
ASADAL / FORM
FIG. 2 is a block diagram showing the configuration and data processing flow of ASADAL / FORM 100 of ASADAL, which is a system for providing a development framework according to the present invention. The main function of ASADAL / FORM100 is that a software product line analyst analyzes a domain (or region) to extract common points and differences between related systems and generate a feature model for the domain. The application program developer can analyze the system and select features that satisfy the requirements of the application program. These functions will be described in detail as follows.

  A feature refers to an attribute or feature within an area of interest to a person associated with a particular area. For example, features can be found by analyzing terminology used among user manuals, software documents, and domain experts. Feature modeling refers to a process of finding features representing common points and differences between systems belonging to a region range from a number of candidate features, and specifying the relationship between them and composition rules. That is, feature modeling means the process of clarifying what is common between similar types of systems, what parts are different, and what kind of differences will occur in the future.

  The ASADAL / FORM 100 creates a feature model by an editor module that supports feature modeling, and the feature model thus created is stored in the ASADAL / ASSE DB 400 so that it can be used by other modules. That is, referring to FIG. 2, the product line analyst 102 analyzes the domain to obtain candidate features (S110). Based on the candidate features obtained in this way, the feature model editor classifies required features that represent common points of the system, selective features that represent differences, and alternative features to create a tree-structured feature model. (S120).

  ASADAL / FORM100 searches for essential features and selective features that represent common points and differences between systems, specifies the relationship and composition rules, and the feature model created by product line analyst 102 matches the composition rules. This function supports a function that can verify whether it is described in detail or whether the relationship between features is normally set (S130). Through such a feature model verification process, the software product line analyst 102 can obtain an effective feature model.

  The requirements of application programs that belong to a region can be specified by selecting the essential features that represent common points with the features that correspond to the application program from the features that represent differences in the feature model for that region. . The application program developer uses the feature selection module of the ASADAL / FORM100 to generate a collection of effective features that meet the requirements of the application program using feature descriptions and synthesis rules from the feature model created by the area analyst. Select features to be

  That is, referring to FIG. 2, the application program developer 104 analyzes the application program and determines its requirements (S140). Then, the application program developer 104 brings the feature model stored in the ASADAL / ASSE DB 400, A feature that satisfies the requirements is selected (S150). Such feature selection information is again stored in the ASADAL / ASSE DB 400.

ASADAL / COMP
FIG. 3 is a block diagram showing the function and data processing flow of ASADAL / COMP200 of ASADAL, which is a system for providing a development framework according to the present invention. The main function of ASADAL / COMP200 is to create a reusable asset component based on the feature model and feature selection information created by ASADAL / FORM100, and a software component suitable for feature selection by macro-processing the asset component And shape management for such components.

Hereinafter, the asset component development process, which is one of the main functions of the ASADAL / COMP 200, will be described in detail with reference to FIG.
Asset components are centered around alternative and selective features that represent differences between application programs retrieved in a feature model so that they can be reused in multiple application programs with diverse requirements. It must be created so that it can respond appropriately when a feature is selected and when it is not selected. The asset component also defines macros that assist in selecting features that can be used when creating the asset component, removing unnecessary code associated therewith, and inserting appropriate code.

  Referring to FIG. 3, the ASADAL / COMP 200 brings a feature model created for the corresponding domain from the ASADAL / ASSE DB 400 in order to create an asset component. ASADAL / COMP200 collects highly relevant features from the essential features defined in the feature model brought from the ASADAL / ASSE DB400, defines asset components that implement them, and selects related to the asset components If there is a target feature and an alternative feature, the component specifies how the component should respond according to the selection (S240). The asset component created in this way is stored in the ASADAL / ASSE DB 400 and used for generating a software component.

  While ASADAL / COMP 200 defines macros that support the selection of features that can be used when creating asset components, the removal of unnecessary code associated therewith, and the insertion of appropriate code, the asset component verification module creates macros A function that verifies the validity of the description and the grammatical errors that sometimes occur is supported (S210). The task of verifying the asset component is a basic task of macro processing at the time of development of the software component, and must be performed before the macro processing.

  As shown in FIG. 3, the ASADAL / COMP 200 brings feature selection information and asset components from the ASADAL / ASSE DB 400 and includes them in the asset component specification based on the feature selection information and asset components thus obtained. The code that implements the unselected features is removed, and the code that implements the selected features is changed appropriately to automatically generate software components ( S220). The software component generated in this way is stored in the ASADAL / ASSE DB 400, sent to the shape management module together with the feature selection information, and shape managed.

  In other words, the shape management module manages the feature selection information and asset component information used when generating the software component, and provides reverse traceability to the feature model and asset component when a problem is found in the software component. The component version is managed (S230).

  For example, if a problem occurs when a software component created by ASADAL / COMP200 is used in an external module, the user can select feature information and assets of the software component from the shape management module of ASADAL / COMP200 to solve the problem. By obtaining the version information of the component, it is possible to obtain a trace until the software component is created. By analyzing such information, it is possible to generate a corrected software component by searching for the root cause that caused the problem of the software component.

ASADAL / OBJ
The ASADAL / OBJ 300 mainly performs design and implementation for application programs, and verification of application programs through simulation on a virtual test bed. In the ASADAL / OBJ300, the control unit is a part for developing an application program for controlling the system, and the environment object is a part for developing a virtual environment in which the application program is actually arranged and executed. It is.

  More specifically, the ASADAL / OBJ 300 uses software components generated by the ASADAL / COMP 200 based on the requirements of the application program in the application program design and implementation process. In ASADAL / OBJ300, software components are used throughout the action and function specification language to provide architectural modeling that represents the relationship between these components and the software components generated by ASADAL / COMP200. The verification of the application program through the simulation on the virtual test bed is performed by the three-dimensional simulation with the virtual environment for testing the application program as the specification through the environmental object modeling of the ASADAL / OBJ300.

FIG. 4 is a block diagram showing the functions of the control unit of the ASADAL / OBJ 300 of ASADAL, which is a system for providing a reuse development framework for feature-oriented software according to the present invention, and the data processing flow thereof.
First, in the software architecture modeling module, the application program developer 301 designs how non-functional elements of features are arranged in a substantial system (S302). In other words, this module determines how to design an architecture for the system by efficiently and appropriately using the operation model and software components that the current ASADAL / ASSE DB 400 has. The architecture model generated in this way is stored in the ASADAL / ASSE DB 400.

  Next, the operation modeling module expresses the system by specifying the functions and actions that the system has (S304). The ASADAL / OBJ300 can refer to the architecture of the system stored in the ASADAL / ASSE DB 400, can make the inside of the system into an operation modeling specification according to the architecture, and the software components generated based on the features The system can be configured by reuse. The ASADAL / OBJ 300 provides specifications that allow the use of software components necessary for system operation, so that the user can conveniently use external software components. In addition, an operation model having the same function as that of other systems stored in the ASADAL / ASSE DB 400 can be reused.

  The validity check of the model is an operation for searching for inconsistencies in the details and error of the model by the logic analyzer when the model obtained from each module is complicatedly detailed. In ASADAL / OBJ300, the application program developer can verify the effectiveness of the operation model and the architecture model, reduce errors that may occur during the generation of automatic code, and increase efficiency (S306 and S308).

  In the development framework according to the present invention, an operation model brought from the ASADAL / ASSE DB 400 can be used as an input to the automatic code generation module, and a code can be generated conveniently in the target program language. In other words, the automatic code generation module provides an environment in which the user can shorten the software development time and easily solve various problems that occur during code creation. The ASADAL / OBJ 300 generates a simulation code for testing in a three-dimensional virtual simulation and a target code (target code) that is arranged and operated in the actual system (S310 and S312). Therefore, the simulation code is generated so that it can be simulated in association with the environmental object during virtual testing, and the target code is generated so that it can be downloaded to the actual system and executed.

FIG. 5 is a block diagram showing the function of the environmental object and the data processing flow of ASADAL / OBJ300 of ASADAL, which is a feature-oriented software reuse development framework according to the present invention.
One of the major features of ASADAL / OBJ300 is to provide an environment in which a system in which specific software is arranged and executed can be virtually modeled. Such an environment is for testing whether the code obtained by automatic code generation can operate normally when it is actually placed in the system. Virtually modeling the environment where the actual code is placed Can do.

  In FIG. 5, the environmental object modeling module includes a three-dimensional shape module for visually expressing a system having various shapes in order to model the shape of an object (S314). Such a morphological model is matched with the operation model (S304), and the motion of the actual object can be virtually represented during the virtual simulation (S310).

  FIG. 6 is a block diagram for showing the I / O mapping operation of ASADAL's ASADAL / OBJ300, which is a feature-oriented software reuse development framework according to the present invention. In ASADAL / OBJ300, virtual input / output (I / O) mapping (S316) that can link data and events between the control unit and environmental objects, and data and events between the actual system and environmental objects can be linked. Actual input / output (I / O) mapping (S318) is possible. The simulation module of the ASADAL / OBJ300 supports the simulation of the target code and the environment object in association with each other by the presence of an input / output correspondence table module that links data and events between the target code and the environment object.

  Referring to FIG. 7, in order to test an application program obtained through architecture modeling and operational modeling, an environment modeling module is used to generate an environment in which the application program is arranged, and then data and events between them are mapped. , I / O mapping module is located in the middle. That is, the application program developer models the control unit and the environmental object with the ASADAL / OBJ 300, and then connects them with an I / O mapping module that can map and simulate events and data (S320 to S324). The ASADAL / OBJ 300 includes a controller simulation module (or engine) and an environment simulation module (or engine) that generate and simulate a simulation code that can be executed with the internal details of the control unit and the environment object as inputs. Visual and intuitive software testing is possible by supporting an I / O handling module that adjusts the engine that simulates the target code and the engine that simulates the environment to exchange data and events with each other. Become. By such intuitive testing, the user can determine whether the target code is normally operable when the target code is actually arranged, and can quickly cope with a problem expected in the system.

  FIG. 8 is a block diagram showing a simulation between an ASADAL / OBJ 300 of ASADAL, which is a system for providing a reuse development framework for feature-oriented software according to the present invention, and an actual system. Referring to FIG. 8, the ASADAL / OBJ 300 maps the data and events between the actual system 330 and the virtual environment simulation (S <b> 328) after downloading the target code from the ASADAL / ASSE DB 400 to the actual system 330. The actual I / O mapping module (S326) is positioned between them. In this way, the data and events that the actual system sends to the actual object can be tested in a virtual environment in advance, so you can test whether the code can work normally before placing it on the actual machine, reducing the test cost it can.

  FIG. 9 is a block diagram showing the configuration of ASADAL's ASADAL / ANALYZER 500, which is a system for providing a product-line development framework for feature-oriented software according to the present invention. The ASADAL / ANALYZER 500 according to the present invention performs a function of checking consistency between models stored in the ASADAL / ASSE DB 400 and checking whether the details of the corresponding model are valid. That is, the asset developer verifies the consistency between the feature model and the asset component (S330), and the application program developer determines the consistency within the operation model, the consistency between the architecture model and the software component, The consistency between the software component and the operation model can be verified (S332 to S336). Such a model checking function is a process that is always performed at the time of design and code generation. Without such a process, correct operation of automatically generated code cannot be guaranteed.

Regarding the specific functions supported by the ASADAL framework described above, (1) Asset development, (2) Application program development, (3) Application program test, (4) Application program maintenance An embodiment from the viewpoint of maintenance will be described.
First Embodiment: Asset Development A method for developing an asset component using the ASADAL module according to the present invention described above is as follows.

  That is, the ASADAL framework is based on analyzing the system around features. Therefore, before developing the asset component, candidate features are obtained through analysis of commonalities and differences to the region, and a completed feature model is created using the feature modeling module of ASADAL / FORM 100 (S110 and S120 in FIG. 2). reference). After the validity of the feature model itself is verified, the verified feature model is stored in the ASADAL / ASSE DB 400 (see S130 in FIG. 2).

  In ASADAL / COMP200, essential features that affect the entire component of the feature model obtained by region analysis, selective features that affect a part of the component, and alternatives that alternatively affect the component. The asset component is detailed using a macro so that the selectability of the target feature can be appropriately handled (see S240 in FIG. 3). The asset component obtained in this way is validated by the asset component verification module and stored in the ASADAL / ASSE DB 400 (see S210 in FIG. 3).

The asset developer verifies whether the asset component created based on the feature has been created consistently by using ASADAL / ANALYZER 500 (see FIG. 9).
Second Embodiment: When the asset component development for the application program development domain (or region) is completed, the application program developer selects only features that satisfy the system requirements from the feature model (S140 and S150 in FIG. 2). reference). Such feature selection is performed by the ASADAL / FORM 100, and the feature selection information is stored in the ASADAL / ASSE DB 400.

  In ASADAL / COMP200, the feature selection information and the asset component are brought from the ASADAL / ASSE DB 400, and a macro processing operation is performed to appropriately correspond the feature selection information to the asset component for generating the software component (see S220 in FIG. 3). ). That is, by performing macro processing on the feature selection information selected according to the user's requirement, only a code that embodies the selected feature is applied to generate a completed software component. The software component thus created is managed by the shape management module of the ASADAL / COMP 200 and stored in the ASADAL / ASSE DB 400 so that it can be reused by an external module (see S230 in FIG. 3).

  As described above, when the software component is generated, an application program is created using the reuse component, and the ASADAL / OBJ 300 that supports architecture modeling, operational modeling, and automatic code generation is used. That is, the ASADAL / OBJ 300 designs an architecture model that satisfies the requirements desired by the user based on various reusable models stored in the ASADAL / ASSE DB 400 (see S302 in FIG. 4). Further, the internal operation model of the system is specified in terms of the internal functions and actions of the system (see S304 in FIG. 4). In the specification from the viewpoint of function, the specification can be made so that an external software component can be used. Therefore, the system can be configured by reusing the software component. Further, the validity of the created architecture model and operation model can be verified by the validity verification module (see S306 and S308 in FIG. 4).

  The operation model generated by the ASADAL / OBJ300 is input to the automatic code generation module, and executable target code and simulation code are automatically generated (see S310 and S312 in FIG. 4). The simulation code thus obtained is a code that enables the control unit and the environment object to operate in conjunction with each other in a virtual environment, and the target code is a code that is actually downloaded to the system and performs a control function. The execution code automatically generated by the ASADAL / OBJ 300 is used in the application program testing stage and is stored in the ASADAL / ASSE DB 400.

Third Embodiment: Application Program Testing Application program testing is performed by (i) virtual simulation through simulation code and environmental objects, and (ii) a method in which target code is downloaded to an actual system and tested. .

  First, the test through the virtual environment simulation specifies the virtual environment in which the program is arranged and executed using the environment modeling module of ASADAL / OBJ300 (see S314 in FIG. 5). In order to map the data and the event between the control unit code and the environmental object, the virtual I / O mapping module maps the data between each other, and the mapping information is stored in the ASADAL / ASSE DB 400 (FIG. 6). (See S316). Next, the ASADAL / OBJ300 can intuitively test the control software with a 3D simulation module created so that the control software for controlling the system and the control software can be arranged and tested in the virtual environment. It is possible to verify whether the automatically generated code operates as intended in the virtual environment (see S320 to S324 in FIG. 7).

  When the execution code is verified in the virtual environment test, it is necessary to verify whether the execution code is actually downloaded by downloading it to the system. The ASADAL / OBJ 300 has real I / O mapping information that allows the actual system and the virtual simulation environment to exchange data and events with each other, thereby verifying whether the execution code operates normally in the actual system (see FIG. 8). (See S326).

Fourth Embodiment: Application Program Maintenance / Maintenance When a test result differs from an expectation in a virtual simulation of ASADAL / OBJ300, an error generated in a software component can be corrected by the following method.
(1) First, consider whether the feature model itself needs to be modified. In this case, it can be corrected through the ASADAL / FORM 100, the feature model thus corrected is stored in the ASADAL / ASSE DB 400, and the software component is generated again by the ASADAL / COMP 200.

  (2) If correction of the feature model is not necessary, consider whether or not the asset component needs to be corrected. If the asset component needs to be modified, it is modified by ASADAL / COMP 200 and stored in the ASADAL / ASSE DB 400, and the software component is generated again by the ASADAL / COMP 200.

(3) When the feature model and the asset component do not need to be corrected, the internal details are corrected through the operation modeling module in ASADAL / OBJ300.
By such a method, a problem occurring in the software component is found, and the ASADAL / OBJ 300 can develop software by testing in a virtual environment with a code corrected through automatic code generation.

FIG. 2 is a block diagram showing a configuration of an ASADAL framework that supports a development environment for a feature-oriented software product line according to the present invention. FIG. 3 is a block diagram showing the configuration of ASADAL / FORM that performs feature modeling and feature selection and the flow of data processing in the development environment of the feature-oriented software product line according to the present invention. FIG. 3 is a block diagram showing the configuration of ASADAL / COMP that performs generation and shape management of asset components and software components and the flow of data processing in the development environment of the feature-oriented software product line according to the present invention. It is a block diagram showing the function of the control unit and the data processing flow of ASADAL / OBJ300 of ASADAL, which is a system for providing a reuse development framework for feature-oriented software according to the present invention. It is a block diagram showing the function of the environmental object of ASADAL / ASJAL / OBJ300 of ASADAL, which is a reusable development framework for feature-oriented software according to the present invention, and its data processing flow. FIG. 3 is a block diagram showing the configuration of ASADAL / OBJ that performs automatic code generation and three-dimensional virtual simulation test and the flow of data processing in the development environment of the feature-oriented software product line according to the present invention. FIG. 3 is a block diagram showing the configuration of ASADAL / OBJ that performs automatic code generation and three-dimensional virtual simulation test and the flow of data processing in the development environment of the feature-oriented software product line according to the present invention. FIG. 3 is a block diagram showing the configuration of ASADAL / OBJ that performs automatic code generation and three-dimensional virtual simulation test and the flow of data processing in the development environment of the feature-oriented software product line according to the present invention. It is a block diagram which shows the structure of ASADAL / ANALYZER which performs consistency verification between models, and a test | inspection of a validity, and the flow of data processing in the development environment of the feature-oriented software product line by this invention.

Claims (12)

A system for providing a development environment for a feature-oriented software product line,
ASADAL / FORM for selecting a feature corresponding to an application program from the feature modeling for a specific region and the features generated by the feature modeling;
ASADAL / COMP that develops asset components based on the feature selection information, generates software components through macro processing, and manages the shape of the software components;
ASADAL / OBJ that performs verification through architecture modeling, operational modeling and automatic code generation, virtual testbed construction and simulation for developing the application software;
An ASADAL / ASSE DB that stores data generated by the ASADAL / FORM, ASADAL / COMP, and ASADAL / OBJ;
A system comprising: ASADAL / ANALYZER for verifying consistency between data stored in the ASADAL / ASSE DB. The ASADAL / FORM is
Based on the candidate features obtained through the analysis of the region, the essential features that represent the common points of the system related to the region, the selective features that represent the differences between the systems, and the alternative features are classified into a tree structure. A feature modeling editor to create a feature model
A feature model verification module that verifies the relationship between the features and specifications according to the synthesis rules of the feature model;
The system according to claim 1, further comprising: a feature selection module that selects a valid feature that meets the requirements of the application program using a description of the feature in the feature model and a synthesis rule.   The system according to claim 2, wherein the feature model and the feature selection information respectively generated by the feature modeling editor and the feature selection module are stored in the ASADAL / ASSE DB. Said ASADAL / COMP is
In the feature model, an asset component development module that specifies how an asset component corresponds according to a selective feature and an alternative feature using a macro;
An asset component verification module that verifies the validity of the grammatical errors and details that occur when creating the macro;
A software component generation module that automatically generates a software component by processing a macro included in an asset component specification based on the feature selection information and changing a code that embodies the selected feature;
The feature management information generated based on the feature selection information and asset component information used when generating the software component is managed, and if a problem is found in the software component, the feature model and asset component are traced back. The system according to claim 1, further comprising: a component shape management module that provides functionality. The asset component development module receives the feature model from the ASADAL / ASSE DB, generates the asset component, and stores the generated asset component in the ASADAL / ASSE DB.
The software component generation module receives the feature selection information and the asset component from the ASADAL / ASSE DB, generates the software component, and stores the generated software component in the ASADAL / ASSE DB.
The system according to claim 4, wherein the shape management information generated by the shape management module is stored in the ASADAL / ASSE DB. The ASADAL / OBJ is
A software architecture modeling module that designs how non-functional elements of features represented in the feature model are arranged in a substantial system to generate a software architecture;
An operation modeling module for generating an operation model that represents the system by specifying the functions and actions of the system with reference to the software architecture;
A model validity verification module for verifying inconsistencies and errors in specifications included in the software architecture and operation model generated by the software architecture modeling module and the operation modeling module;
The system according to claim 1, further comprising: an automatic code generation module that generates a target code and a simulation code in a target program language by using a function and an action detail obtained based on the operation model. The ASADAL / OBJ is
An environmental object modeling module that virtually models a system in which the application program is arranged and executed to generate an environmental object;
A controller simulation module that executes the target code in a control unit that develops an application program for controlling the system;
An environment simulation module for executing the simulation code on the environment object;
A virtual input / output mapping module that links data and events transmitted and received between the controller simulation module and the environment simulation module;
The system according to claim 6, further comprising: an actual input / output mapping module that connects data and events transmitted / received between the system and the environment simulation module.   The environmental object modeling module generates a three-dimensional form for visually expressing a system having various shapes in order to model the shape of the environmental object, and the environmental simulation module generates the three-dimensional form. The system according to claim 7, wherein a three-dimensional simulation is performed by matching with the operation model.   The target code is downloaded from the system to an actual system controller, and the system performs simulation by communicating events and data with the environment simulation module through the actual input / output mapping module. Item 8. The system according to Item 7.   The system according to claim 6, wherein the operation modeling module uses a reusable software component input from outside the system by a function specification method. The software architecture modeling module stores the generated software architecture in the ASADAL / ASSE DB,
The operational modeling module generates the operational model in response to the transmission of the software architecture stored in the ASADAL / ASSE DB, and stores the generated operational model in the ASADAL / ASSE DB. The system according to claim 6. Said ASADAL / ANALYZER is
A module for checking consistency between the feature model and the asset component;
A module for checking the consistency of the operational model;
A module for checking consistency between the architectural model and the software component;
The system of claim 1, comprising: a module that checks consistency between the software component and the operational model.

Images