KR20070000732A - Asadal : system for providing feature-oriented software product line engineering environment - Google Patents

Abstract

An ASADAL(A System Analysis and Design Aided tooL) system for offering a feature-based software product line development environment is provided to support software product line methodology by defining an ASADAL framework supporting the methodology of feature-based software product line engineering, a structure of each module forming an ASADAL, and a function and data flow of each module. An ASADAL form(100) models features for a specific area and selects the features corresponding to an application program among the features generated by feature modeling. An ASADAL component(200) develops an asset component based on feature selection information, generates a software computer through a macro process, and manages a shape of the software component. An ASADAL object(300) models an architecture and operation for the application software development, automatically generates codes, builds a virtual test bed, and performs a test through simulation. An ASADAL asset database(400) stores data generated from each part. An ASADAL analyzer(500) verifies consistency of the data stored in the ASADAL asset database.

Description

Asadaal: System for providing feature-based software product line development environment {ASADAL: SYSTEM FOR PROVIDING FEATURE-ORIENTED SOFTWARE PRODUCT LINE ENGINEERING ENVIRONMENT}

1 is a block diagram showing the configuration of an ASADAL framework supporting a feature-based software product line development environment in accordance with the present invention;

2 is a block diagram showing a configuration and data processing flow of an ASADAL / FORM performing feature modeling and feature selection in a feature-based software product line development environment according to the present invention;

3 is a block diagram showing a configuration and data processing flow of an ASADAL / COMP performing creation and configuration management of asset components and software components in a feature-based software product line development environment according to the present invention;

6 to 8 are block diagrams illustrating the configuration and data processing flow of ASADAL / OBJ performing automatic code generation and 3D virtual simulation testing in a feature-based software product line development environment according to the present invention.

9 is a block diagram illustrating a configuration and data processing flow of ASADAL / ANALYZER for performing consistency verification and validation between models in a feature-based software product line development environment according to the present invention.

TECHNICAL FIELD The present invention relates to a feature-based software product line development environment. In particular, the software product line methodology is applied to a specific domain (or region) to generate feature selection and reusable asset components for domain analysis and application development. , Feature-based software that facilitates software product line development by supporting the creation of software components through macro-processing, configuration management of components, application software development using software components, and software testing in virtual environments A system for implementing a product line development environment.

The focus of software reuse technology to increase the productivity of software development has shifted from reuse of source code to reuse of software design, and from reuse of software design to reuse based on domain engineering. The reason for the change of the software reuse technology is that the reuse of the design must be preceded in order to reuse the source code, and in order to reuse the design, the area assets commonly used in the application area must be developed through the area engineering. . Thus, software reuse research has been focused on domain analysis and domain engineering for many years.

In the study of software reuse technology, the domain engineering approach is to develop a highly reusable component through extensive analysis of the application area. In many cases, however, this approach tended to include all products in the domain, which in turn increased the cost and duration of software development. In addition, in an effort to maximize software reusability, emphasizing the layering of software structures and encapsulation for information concealment has resulted in a problem of developing a system with poor performance. As described above, it is difficult to determine the extent of the appropriate area and the degree of reusability in attempting to reuse the software around the application area.

To solve some of the problems mentioned above, a paradigm of software product line engineering has been proposed. According to this paradigm, software reuse is a carefully planned plan for reusing specific software product lines. In other words, software product line engineering can clarify the scope of area analysis and the development scope of software product line assets based on the results of analyzing the market situation that a company wants to enter.

Software product line engineering analyzes commonalities and variability among software that provides similar functionality targeting one or more markets to develop the software assets that are the core of the software product line. Based on this, we propose a software architecture that can accommodate change and develop reusable components. Recently, interest and recognition in software product line engineering for strategic reuse of such software is gradually increasing, and research on this is being actively conducted.

However, according to the concept of software product line engineering, there is still a system that provides a systematic and effective software development environment that supports the overall methodology of software product line engineering, such as analyzing commonalities and differences of domains, developing flexible software architecture and reusable components. It is not presented.

The present invention is to improve the above-mentioned problems of the prior art, and defines an ASADAL (AS System Analysis and Design Aided tooL) framework supporting the methodology of the feature-based software product line engineering, and each module constituting ASADAL. The goal is to provide a feature-based software reuse development environment system that supports the software product line methodology by defining the structure, module functionality, and data flow of the.

In addition, the present invention obtains reusable software assets based on feature modeling results of analyzing commonalities and differences of domains using such a systematic development environment, and efficiently develops application software using software assets. By testing on a three-dimensional simulation basis, the goal is ultimately to obtain high quality software based on the concept of software product line engineering.

The system for providing a feature-based software product line development environment according to the present invention for achieving the above object is, ASADAL / to select a feature corresponding to the application from the feature modeling for the specific region and the feature generated by the feature modeling; FORM, ASADAL / COMP for developing asset components based on the feature selection information, generating software components through macro processing and shape management of the software components, architecture modeling and operational modeling for the application software development, and automatic ASADAL / OBJ which performs verification through code generation, virtual test bed construction and simulation, ASADAL / ASSET DB which stores data generated by the ASADAL / FORM, ASADAL / COMP and ASADAL / OBJ, and ASADAL / ASSET DB Includes ASADAL / ANALYZER to verify consistency between data stored in

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a block diagram showing the configuration of the ASADAL (A System Analysis and Design Aided too L) framework according to the present invention. The system according to the present invention includes five components, ASADAL / FORM 100, ASADAL / COMP 200, ASADAL / OBJ 300, ASADAL / ASSET DB 400 and ASADAL / ANALYZER 500. Among the components of the system shown in FIG. 1, ASADAL / FORM 100, ASADAL / COMP 200, ASADAL / OBJ 300, and ASADAL / ANALYZER 500 may run on one computer or on multiple computers connected by a network. Can be implemented in software.

In the system according to the present invention, the ASADAL / FORM 100 performs the function of selecting the feature corresponding to the feature modeling and application program for the region, and the ASADAL / COMP 200 performs the development and macro processing of the asset component. It performs the functions of software component creation and component configuration management. ASADAL / OBJ 300 provides architectural modeling and operational modeling for application software development, automatic code generation, and verification by building and simulating a virtual test bed. In addition, the ASADAL / ASSET DB (400) stores the output generated in each module described above, the ASADAL / ANALYZER (500) verifies the consistency between the outputs stored in the ASADAL / ASSET DB (400).

Hereinafter, with reference to the accompanying drawings, each module constituting the ASADAL which is a system for providing a development framework according to the present invention will be described in detail.

ASADAL / FORM

Figure 2 is a block diagram showing the configuration and data processing flow of the ASADAL / FORM 100 of ASADAL which is a system providing a development framework according to the present invention. The main function of ASADAL / FORM 100 is that the software product line analyst analyzes domains (or domains) and extracts feature and common features between related systems in feature units to create feature models for domains. Analyzes the system and selects features that meet the application's requirements.

A feature refers to an attribute or feature within a region of interest to those associated with a particular region. For example, a feature can be found by analyzing terms used between user manuals, software documentation, and domain experts. Feature modeling refers to a process of finding features representing commonalities and differences among systems belonging to an area range among many candidate features and specifying their relations and synthesis laws. In other words, feature modeling is the process of clarifying what is common among similar types of systems, what is different, and what will happen in the future.

The ASADAL / FORM 100 creates a feature model through an editor module that supports feature modeling. The feature model is then stored in the ASADAL / ASSET DB 400 to 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 thus obtained, a feature model of a tree structure is created by classifying essential features representing commonalities, selective features representing differences, and alternative features using the feature model editor (S120).

ASADAL / FORM 100 finds the essential features and the optional features representing the commonalities and differences among the systems, and specifies their relations and the synthesis law.The feature model created by the product line analyst 102 is specified according to the synthesis law. It supports a function that can verify whether the relationship between the features are properly set (S130). Through the feature model verification process, the software product line analyst 102 may obtain a valid feature model.

The requirements of an application program within an area can be specified by selecting the required features that represent the features in common with the features corresponding to the application among the features representing the difference in the feature model for the area. Application developers can use the feature selection module of ASADAL / FORM 100 to create a feature set in the feature model created by the domain analyst, using feature descriptions, composition rules, etc. to meet the requirements of the application. Select them.

That is, referring to FIG. 2, the application developer 104 analyzes an application to determine its requirements (S140), and then imports a feature model stored in the ASADAL / ASSET DB 400 to obtain the requirements. Select features to satisfy (S150). The feature selection information is stored in the ASADAL / ASSET DB 400 again.

ASADAL / COMP

3 is a block diagram showing the function and data processing flow of ASADAL / COMP 200 of ASADAL, a system providing a development framework according to the present invention. The main functions of ASADAL / COMP 200 are to create a reusable asset component based on the feature model and feature selection information created on the ASADAL / FORM 100, and to process the asset component into a macro to select a software component for feature selection. Creating and performing configuration management for these components.

Hereinafter, a process of developing an asset component which is one of the main functions of the ASADAL / COMP 200 will be described in detail with reference to FIG. 3.

Asset components can be reused in multiple applications with varying requirements, with alternative features and optional features representing differences between applications retrieved from the feature model, when and when those features are selected and not selected. Each must be prepared to respond appropriately. In addition, the asset component defines macros that support the selection of features that can be used when creating the asset component, the removal of unnecessary code, and the insertion of appropriate code.

Referring to FIG. 3, the ASADAL / COMP 200 imports the feature model created for the domain from the ASADAL / ASSET DB 400 to create an asset component. ASADAL / COMP 200 defines an asset component that implements them by grouping the relevant features among the mandatory features defined in the feature model taken from ASADAL / ASSET DB 400, and selects optional features and alternatives related to that asset component. If features are present, a macro specifies how the component should respond according to their selection (S240). The asset component thus created is stored in the ASADAL / ASSET DB 400 and used to generate software components.

ASADAL / COMP (200) defines macros that support the selection of features that can be used when creating an asset component, thereby eliminating unnecessary code and inserting the appropriate code. It supports the function to validate the error and specification (S210). Validating asset components must be performed before macro processing because it is the basic task of macro processing in software component development.

As shown in FIG. 3, the ASADAL / COMP 200 imports the feature selection information and the asset component from the ASADAL / ASSET DB 400, and is included in the asset component specification based on the feature selection information and the asset component thus obtained. The macros are processed according to their meanings, and the software components are automatically generated by removing codes implementing the non-selected features and appropriately changing the codes implementing the selected features (S220). The generated software component is stored in the ASADAL / ASSET DB 400, and is passed to the configuration management module along with the feature selection information to be managed.

That is, the configuration management module manages the feature selection information and the asset component information used when the software component is generated, and provides a traceback of the feature model and the asset component when a problem is found in the software component, and manages the version of the component. (S230).

For example, if a problem occurs while a software component created by the ASADAL / COMP 200 is used in an external module, the user may ask the configuration management module of the ASADAL / COMP 200 to solve the problem. By obtaining the feature selection information and the version information of the asset component, you can get a trace until the software component is created. By analyzing this information, you can find the root cause of the software component problem and create a modified software component.

ASADAL / OBJ

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

More specifically, the ASADAL / OBJ 300 uses software components generated by the ASADAL / COMP 200 based on the requirements of the application in the design and implementation of the application. Software components in ASADAL / OBJ 300 are used through behavioral and functional specification languages, and architectural modeling is provided that represents the relationship between these components and software components generated in ASADAL / COMP 200. In addition, the verification of the application through the simulation on the virtual test bed is performed through the three-dimensional simulation by specifying the virtual environment to test the application through the environment object modeling of the ASADAL / OBJ (300).

Figure 4 is a block diagram showing the function of the control unit and the data processing flow of the ASADAL / OBJ 300 of the ASADAL system that provides a feature-based software reuse development framework according to the present invention.

First, in the software architecture modeling module, the application developer 301 designs how to arrange the non-functional elements of the feature in the actual system (S302). That is, the module determines how to design the architecture for the system by efficiently using the operating model and software components of the current ASADAL / ASSET DB 400. The generated architecture model is stored in the ASADAL / ASSET DB (400).

Next, the operational modeling module expresses the system by specifying the functions and actions the system has inside (S304). ASADAL / OBJ (300) can refer to the architecture of the system stored in the ASADAL / ASSET DB (400) to specify the operating modeling of the system according to the architecture, and reuse the software components generated on the basis of the feature It can also be configured. The ASADAL / OBJ 300 provides a specification for using the software components required for operating the system, so that the user can conveniently use the external software components. In addition, an operation model having the same function as that of another system stored in the ASADAL / ASSET DB 400 may be reused.

Model validation is the task of looking for inconsistencies in specifications or model errors through a logic analyzer when the models obtained in each module are complexly specified. In the ASADAL / OBJ (300), the application developer can reduce the errors that can occur during automatic code generation by validating the operational model and the architecture model (S306 and S308).

In the development framework according to the present invention, an operation model taken from the ASADAL / ASSET DB 400 can be conveniently generated as a target programming language by using an automatic code generation module as an input. In other words, the automatic code generation module reduces the software development time and provides an environment where users can easily solve various problems that occur when writing code. The ASADAL / OBJ 300 generates a simulation code for testing in a three-dimensional virtual simulation and a control code (embedded) to operate in a real system (S310 and S312). Therefore, the simulation code is generated to be simulated by interlocking with an environment object during virtual testing, and the control code is generated to be downloaded and executed on the actual system.

5 is a block diagram showing the function of the environment object (environment object) of the ASADAL / OBJ 300 of ASADAL, which is a feature-based software reuse development framework in accordance with the present invention and its data processing flow.

One of the great features of the ASADAL / OBJ 300 is that it provides an environment for virtually modeling the system on which particular software is deployed and executed. This environment is designed to test whether the code obtained through automatic code generation can work properly when deployed on a real system. The environment can be modeled virtually.

In FIG. 5, the environment object modeling module is composed of a three-dimensional shape module for visually representing a system having various shapes in order to model a shape of an object (S314). This shape model may be matched with the operation model S304 to virtually express the movement of the real object during the virtual simulation (S310).

6 is a block diagram illustrating the operation of I / O mapping of ASADAL / OBJ 300 of ASADAL, which is a feature-based software reuse development framework according to the present invention. In ASADAL / OBJ 300, a virtual input / output (I / O) mapping (S316) for connecting data and events between a control unit and an environment object and an actual input / output (I / O) for connecting data and events between a real system and an environment object ) Mapping (S318) is possible. The simulation module of ASADAL / OBJ 300 has an I / O mapping table module that connects data and events between control code and environment objects so that the control code and environment objects can be simulated together. Support.

Referring to FIG. 7, in order to test an application obtained through architecture modeling and operational modeling, an environment modeling module generates an environment in which an application is to be deployed, and then I / O mapping module to map data and events between the two. In the middle. That is, the application programmer models the control unit and the environment object in the ASADAL / OBJ 300, and then connects the event and the data between them through an I / O mapping module that can be simulated (S320 to S324). Also, the ASADAL / OBJ 300 includes a controller simulation module (or engine) and an environment simulation module (or engine) for generating and simulating executable simulation code by inputting a control unit and an internal specification of an environment object. Visual and intuitive software testing is possible by supporting an engine that simulates control code and an I / O handling module that coordinates the exchange of data and events with each other. This intuitive testing allows the user to determine if the control code is actually working when it is actually deployed and to quickly cope with the problems expected in the system.

8 is a block diagram illustrating a simulation between an ASADAL / OBJ 300 and an actual system of ASADAL, which is a system providing a feature-based software reuse development framework according to the present invention. Referring to FIG. 8, after the ASADAL / OBJ 300 downloads the target code from the ASADAL / ASSET DB 400 to the real system 330, data and events between the real system 330 and the virtual environment simulation S328. In order to map the real I / O mapping module (S326) is placed in the middle of them. In this way, data and events sent by real systems to real objects can be pretested in a virtual environment, enabling you to test whether your code can work properly before deploying on a real machine, and reduce your testing costs.

9 is a block diagram showing the configuration of ASADAL / ANALYZER 500 of ASADAL, a system that provides a feature-based software product line development framework in accordance with the present invention. The ASADAL / ANALYZER 500 according to the present invention performs a function of checking consistency between models stored in the ASADAL / ASSET DB 400 and checking whether a specification of the corresponding model is valid. That is, the asset developer verifies the consistency between the feature model and the asset component (S330), and the application developer may verify the consistency between the operational model, the consistency between the architectural model and the software component, and the consistency between the software component and the operational model ( S332 to S336). This model checking function is a process that must be performed during design and code generation. Without this process, automatic operation of automatically generated code cannot be guaranteed.

Specifically, the ASADAL framework described above supports (1) asset development, (2) application development, (3) application testing, and (4) Let us look through the embodiment seen from the perspective of application maintenance (application maintenance).

Example 1: Asset Development

A method of developing an asset component using the modules of the ASADAL according to the present invention described above is as follows.

In other words, the ASADAL framework is based on analyzing the system around features. Therefore, before developing an asset component, candidate features are obtained through analysis of commonalities and differences for the regions, and a completed feature model is created using the feature modeling module of ASADAL / FORM 100 (see S110 and S120 in FIG. 2). ). After validating the feature model itself, the verified feature model is stored in the ASADAL / ASSET DB 400 (see S130 of FIG. 2).

In the ASADAL / COMP 200, for the feature model obtained through the area analysis, the selection of mandatory features affecting the entire component, optional features affecting a part of the component, and alternative features affecting the component alternatively Asset components are specified using macros to appropriately address the possibilities (see S240 in FIG. 3). The asset component thus obtained is validated by the asset component verification module and stored in the ASADAL / ASSET DB 400 (see S210 of FIG. 3).

The asset developer verifies whether the asset component created on the basis of the feature is consistently created through the ASADAL / ANALYZER 500 (see FIG. 9).

Second Embodiment: Application Development

Once the development of the asset component for the domain (or region) is complete, the application developer selects only the features that meet the system requirements in the feature model (see S140 and S150 in FIG. 2). The selection of the feature is performed in the ASADAL / FORM 100, and the feature selection information is stored in the ASADAL / ASSET DB 400.

ASADAL / COMP (200) is a macro-processing operation to take the feature selection information and asset components from the ASADAL / ASSET DB (400) to properly match the feature selection information to the asset component for generation of software components (See S220 of FIG. 3). In other words, by processing the feature selection information selected according to the requirements of the user by macro, only the code for implementing the selected features is applied to generate the completed software component. The software component thus created is managed through the configuration management module of the ASADAL / COMP 200, and is stored in the ASADAL / ASSET DB 400 to be reused in an external module (see S230 of FIG. 3).

As described above, once the software component is created, the ASADAL / OBJ 300 is used to support architecture modeling, operational modeling, and automatic code generation to create applications using reusable components. That is, the ASADAL / OBJ 300 designs an architecture model that satisfies the requirements of the user based on various reusable models stored in the ASADAL / ASSET DB 400 (see S302 of FIG. 4). It also specifies the internal operating model of the system in terms of the internal functions and behavior of the system (see S304 in FIG. 4). In the specification of the functional point of view, the specification can be made to use external software components so that the system can be configured by reusing the software components. In addition, validation of the created architectural model and operational model can be performed through the validation module (see S306 and S308 of FIG. 4).

The operation model generated by the ASADAL / OBJ 300 is an input of an automatic code generation module, and an executable target code and a simulation code are automatically generated (see S310 and S312 of FIG. 4). The simulation code thus obtained is a code that allows the controller and environment objects to interlock with each other in a virtual environment, and the target code is a code that is downloaded to an actual system and performs a control function. Execution codes automatically generated by the ASADAL / OBJ 300 are used in the testing phase of the application and are stored in the ASADAL / ASSET DB 400.

Third Embodiment: Application Testing

Testing of the application is accomplished by (i) virtual simulations using simulation code and environment objects, and (ii) downloading and testing the target code on a real system.

Testing through a virtual environment simulation first specifies a virtual environment in which a program is placed and executed using the environment modeling module of the ASADAL / OBJ 300 (see S314 of FIG. 5). In order to map data and events between the code of the control unit and the environment objects, data is mapped to each other through the virtual I / O mapping module, and the mapping information is stored in the ASADAL / ASSET DB 400 (see S316 of FIG. 6). . Next, ASADAL / OBJ (300) can intuitively test the control software through a three-dimensional simulation module that can be placed in the virtual environment by placing the control software and control software to control the system, and through this virtual environment It is possible to verify that the automatically generated code works as intended in the virtual environment (see S320 to S324 in FIG. 7).

Once the executable code has been verified in the virtual environment testing, you need to download the executable code to a real system to verify that it works. The ASADAL / OBJ 300 may verify that the execution code works properly in the real system by having real I / O mapping information in which the real system and the virtual simulation environment exchange data and events with each other (S326 of FIG. 8). Reference).

Fourth Embodiment: Application Maintenance

If the result of the test in the virtual simulation of the ASADAL / OBJ 300 is different from the expected, the error occurred in the software component can be corrected through the following method.

(1) First, consider whether the feature model itself needs correction. In this case, it can be modified through the ASADAL / FORM 100. The modified feature model is stored in the ASADAL / ASSET DB 400, and the software component is re-created in the ASADAL / COMP 200.

(2) If modification of the feature model is not required, consider whether the asset component needs modification. If the asset component needs to be modified, it is modified in ASADAL / COMP (200), stored in ASADAL / ASSET DB (400), and the software component is regenerated in ASADAL / COMP (200).

(3) If the feature model and asset component do not require modification, the ASADAL / OBJ 300 modifies the internal specification through the operational modeling module.

After finding the problem occurring in the software component through the above method, the ASADAL / OBJ 300 may develop the software by testing in a virtual environment with the modified code through automatic code generation.

As described above, ASADAL, a system that provides a feature-based software reuse development environment according to the present invention, clearly analyzes the functional, environmental, technical, and implementation commonalities and differences of systems in a domain forming a similar system to develop components. Reflecting has the advantage of increasing the reusability and adaptability of the component.

In addition, in the development environment according to the present invention, the model can be verified from the initial stage of software development, and errors of the model can be found through simulation. Therefore, this analysis can increase the reliability of the model and can significantly reduce the development cost because it can check for critical errors in the early stages of software development.

Software inspection through the three-dimensional simulation according to the present invention has the advantage that can perform a variety of inspection at a low cost since the environment similar to the real world is built through the three-dimensional modeling and performing the software inspection and evaluation based on this . In particular, since a real-time control system is often an embedded system, software inspection and evaluation of an external hardware environment and an internal software system can enhance the reliability of the software. Inspection costs can also be significantly reduced.

The development environment according to the present invention provides a systematic framework that supports all steps of software analysis, design, implementation, and testing, thereby obtaining meaningful output at each step. In addition, the development environment according to the present invention is designed such that efficient reuse of software functions, and this reuse technique can be widely applied to various areas of software development.

Claims (12)

A system for providing a feature-based software product line development environment, ASADAL / FORM for selecting the feature corresponding to the application from the feature modeling for the specific region and the feature generated by the feature modeling; ASADAL / COMP, which develops an asset component based on the feature selection information, generates a software component through macro processing, and performs shape management of the software component; ASADAL / OBJ, which performs architecture modeling and operational modeling for the application software development, automatic code generation, and verification by building and simulating a virtual test bed, An ASADAL / ASSET DB for storing data generated by the ASADAL / FORM, ASADAL / COMP and ASADAL / OBJ, Includes ASADAL / ANALYZER for verifying the consistency between the data stored in the ASADAL / ASSET DB system. The method of claim 1, The ASADAL / FORM, Based on the candidate features obtained through the analysis of the region, essential features representing the commonalities of the systems related to the region, selective features representing the differences between the systems, and alternative features are classified to create a feature structure composed of a tree structure. Feature modeling editor, Feature model verification module for verifying whether the specification according to the relationship between the feature and the composition rule of the feature model, And a feature selection module for selecting a valid feature that meets the requirements of the application program by using the feature description and composition rule of the feature model. system. The method of claim 2, The feature model and the feature selection information generated in the feature modeling editor and the feature selection module are stored in the ASADAL / ASSET DB. system. The method of claim 1, ASADAL / COMP, An asset component development module that specifies, using a macro, how an asset component corresponds to an optional feature and an optional feature in the feature model; Asset component verification module for validating the grammatical errors and specifications that occur when the macro is written, A software component generation module configured to process a macro included in the asset component specification based on the feature selection information to change a code for implementing the selected features to automatically generate a software component; Component configuration management based on the feature selection information and asset component information used in the creation of the software component and manages the configuration management information. If a problem is found in the software component, the component configuration management provides traceback to the feature model and the asset component. Characterized in that it comprises a module system The method of claim 4, wherein The asset component development module receives the feature model from the ASADAL / ASSET DB to generate the asset component, and stores the generated asset component in the ASADAL / ASSET DB. The software component generation module receives the feature selection information and the asset component from the ASADAL / ASSET DB to generate the software component, and stores the generated software component in the ASADAL / ASSET DB. The configuration management information generated by the configuration management module is stored in the ASADAL / ASSET DB, characterized in that system. The method of claim 1, The ASADAL / OBJ, A software architecture modeling module for creating a software architecture by designing how to place non-functional elements of features represented in the feature model in a practical system, An operation modeling module for generating an operation model representing the system by specifying functions and behaviors of the system with reference to the software architecture; A model validation module for verifying inconsistencies and errors in specifications included in the software architecture model and the operating model generated by the software architecture modeling module and the operational modeling module, And an automatic code generation module for generating a control code and a simulation code in a target programming language using a specification of functions and behaviors obtained based on the operational model. system. The method of claim 6, The ASADAL / OBJ, An environment object modeling module for generating an environment object by virtually modeling a system in which the application is to be executed and executed; A controller simulation module for executing the control code in a controller for developing 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 for connecting data and events transmitted and received between the controller simulation module and the environment simulation module; And an actual input / output mapping module for connecting data and events transmitted and received between the system and the environment simulation module. system. The method of claim 7, wherein The environment object modeling module generates a three-dimensional shape for visually representing a system having various shapes to model the shape of the environment object, and the environment simulation module matches the three-dimensional shape with the operational model. Characterized in that to perform a three-dimensional simulation system. The method of claim 7, wherein The target code is downloaded from the system to a controller of an actual system, and the system performs simulation by communicating an event and data with the environment simulation module through the actual input / output mapping module. system. The method of claim 6, The operational modeling module uses reusable software components input from the outside of the system through a method of functional specification. system. The method of claim 6, The software architecture modeling module stores the generated software architecture in the ASADAL / ASSET DB, The operational modeling module receives the software architecture stored in the ASADAL / ASSET DB, generates the operational model, and stores the generated operational model in the ASADAL / ASSET DB. system. The method of claim 1, The ASADAL / ANALYZER, 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, And a module for checking consistency between the software component and the operational model. system.

Images