WO2007001108A1

WO2007001108A1 - System for providing feature-oriented software product line engineering environment

Info

Publication number: WO2007001108A1
Application number: PCT/KR2005/003651
Authority: WO
Inventors: Kyo C. Kang
Original assignee: Postech Foundation; Postech Academy-Industry Foundation
Priority date: 2005-06-28
Filing date: 2005-11-01
Publication date: 2007-01-04
Also published as: JP2007012003A; KR100744886B1; KR20070000732A

Abstract

The present invention comprises an ASAD AL(a system analysis and design aided tool) for implementing a feature-oriented software product line engineering environment capable of facilitating a software product line development, through an appliance of a software product line methodology to a specific domain, by way of supporting a feature analysis of the domain, a feature selection for an application program development, a generation of a reusable asset component, a generation of a software component using a macro-processing and a configuration management of the software component, a development of an application software using the software component and a software testing in a virtual environment. The system providing a feature-oriented software product line development environment is advantageous in that reusability and applicability of the component are enhanced by precisely analyzing functional, environmental, technical and implemental commonalities and variabilities of similar systems in a domain and then applying the analysis result to the component development.

Description

SYSTEM FOR PROVIDING FEATURE-ORIENTED SOFTWARE PRODUCT LINE ENGINEERING ENVIRONMENT

Technical Field

[1] The present invention relates to a feature-oriented software product line development environment; and, more particularly, to a system for implementing a feature-oriented software product line engineering environment capable of facilitating a software product line development, through an appliance of a software product line methodology to a specific domain, by way of supporting a feature analysis of the domain, a feature selection for an application program development, a generation of a reusable asset component, a generation of a software component using a macro- processing and a configuration management of the software component, a development of an application software using the software component and a software testing in a virtual environment.

[2]

Background Art

[3] The emphasis of a software reuse technology for enhancing a productivity of a software development has been moved from focusing on a reuse of a source code to focusing on a reuse of software design and then to focusing on a reuse based on domain engineering. The reason for the change in the software reuse technology is that the design needs to be reused in order to reuse the source code and, further, a domain asset commonly used in an application domain needs to be developed in advance by domain engineering in order to reuse the design. Accordingly, the study on the software reuse has been focused on a domain analysis and the domain engineering for the past few years.

[4] In the study on the software reuse technology, a domain engineering access method performs a wide analysis on an application domain to develop a highly reusable component. However, in most cases, such access method tends to include every product in a domain, thereby increasing costs and time required for developing software.Further, if a layering of a software structure and an encapsulation for an information hiding are emphasized too much to maximize reusability of the software, a system developed in the end becomes of a very low efficient one. Therefore, it is difficult to determine a proper range of a domain and an appropriate degree of the reusability in reusing the software in the application domain.

[5] In order to overcome a part of the aforementioned drawbacks, there has been suggested a paradigm of a software product line engineering. According to the paradigm, the software reuse is carried out under a carefully established plan to reuse a specific software product line. In other words, in accordance with the software product line engineering, it is possible to precisely define a scope of a domain analysis and a developing scope of a software product line asset based on a market status analysis result.

[6] The software product line engineering analyzes commonalities and variabilities between software products for providing similar functions to one or more target markets in order to develop a software asset serving as a core of the software product line, thereby enabling to suggest a plan for developing a reusable component and asoftware architecture capable of dealing with changes. Recently, there has been an increased interest and awareness of the software product line engineering for a strategic software reuse, and a study thereon is also being vitalized.

[7] However, there has not yet been suggested a system capable of providing a systematic and an effective software developing environment for supporting an entire methodology of the software product line engineering, e.g., an analysis of commonalities and variabilities between domains, a development of a flexible software architecture and a reusable component or the like in accordance with a concept of the software product line engineering. Disclosure of Invention

Technical Problem

[8] It is, therefore, a primary object of the present invention to provide a feature- oriented software reuse engineering environment system for supporting a software product line methodology by defining a system analysis and design aided tool (ASADAL) framework for supporting a methodology of a feature-oriented software product line engineering and also by defining a structure and a function of each module included in the ASADAL and a data flow in the module.

[9] It is another object of the present invention to provide an achievement of high- quality software pursuant to a concept of the software product line engineering by obtaining a reusable software asset based on a feature modeling result acquired through an analysis of commonalities and variabilities between domains in the systematic development environment; effectively developing application software through a utilization of the software asset; and testing the application software through a three- dimensional simulation.

[10]

Technical Solution

[11] In accordance with the present invention, there is provided a system for providing a feature-oriented software product line development environment, which includes: an ASADAL/FORM for performing a feature modeling in a specific domain and selecting a feature corresponding to an application program from features generated by the feature modeling; an ASADAL/COMP for developing an asset component based on feature selection information, producing and performing a generation of a software component through the use of a macro-processing and a configuration management of the software component; an ASADAL/OBJ for performing an architecture modeling and an operation modeling necessary to develop an application software, an automatic code generation, an establishment of a virtual test bed and a validation through a simulation thereof; an ASADAL/ASSET DB for storing therein data generated by the ASADAL/FORM, the ASADAL/COMP and the ASADAL/OBJ; and an ASADAL/ ANALYZER for verifying consistency between the data stored in the ASADAL/ ASSET DB. [12]

Advantageous Effects

[13] According to the present invention, the ASADAL serving as a system for providing a feature-oriented software reuse development environment in accordance with the present invention is advantageous in that reusability and applicability of the component are enhanced by precisely analyzing functional, environmental, technical and im- plemental commonalities and variabilities of similar systems in a domain and then applying the analysis result to the component development.

[14] Further, in the development environment in accordance with the present invention, a model can be verified in an initial step of the software development and, further, the errors of the model can be discovered by a simulation. Due to the analysis, the reliability of the model can be increased and the significant errors can be checked in the initial step of the software development, which greatly reduces a development cost.

[15] In the software test using the three dimensional simulation in accordance with the present invention, an environment similar to the actual real world is established by a three dimensional modeling and, then, the software test and evaluation are performed based on the established environment, so that various tests can be performed at a low cost. Especially, since a real-time control system is mostly an embedded system, the software test and evaluation for checking whether or not an external hardware environment and an inner software system normally interact can increase the reliability of the software and also can greatly reduce the test cost of the system.

[16] The development environment in accordance with the present invention provides a systematic framework for supporting every step of analyzing, designing, implementing and testing the software. Accordingly, significant products can be obtained from each step. Further, the development environment in accordance with the present invention is designed such that the software can be effectively reused, and the reuse technique can be applied to a wide range of software developments. [17]

Brief Description of the Drawings

[18] The above and other objects and features of the present invention will become apparent from the following description of preferred embodiments, given in conjunction with the accompanying drawings, in which:

[19] Fig. 1 is a block diagram showing a composition of an ASADAL framework for supporting a feature-oriented software product line engineering environment in accordance with the present invention;

[20] Fig. 2 describes a block diagram illustrating a data processing flow and a composition of an ASADAL/FORM for performing a feature modeling and a feature selection in the feature-oriented software product line engineering environment in accordance with the present invention;

[21] Fig. 3 provides a block diagram depicting a data processing flow and a composition of an ASADAL/COMP for performing a generation and a configuration management of an asset component and a software component in the feature-oriented software product line engineering environment in accordance with the present invention;

[22] Figs. 4 to 8 present block diagrams showing a data processing flow and a composition of an ASADAL/OBJ for performing an automatic code generation and a three-dimensional virtual simulation testing in the feature-oriented software product line engineering environment in accordance with the present invention; and

[23] Fig. 9 represents a block diagram illustrating a data processing flow and a composition of an ASAD AL/ ANAL YZER for checking consistency and validity between models in the feature-oriented software product line engineering environment in accordance with the present invention.

[24]

Best Mode for Carrying Out the Invention

[25] Hereinafter, preferred embodiments of a plasma processing method in accordance with the present invention will be described in detail with reference to accompanying drawings.

[26] Referring to Fig. 1, there is shown a block diagram showing a composition of a system analysis and design aided tool (herein after referred to as 'ASADAL') framework serving as a feature-oriented software product line engineering environment in accordance with the present invention. A system in accordance with the present invention includes five components, i.e., an ASADAL/FORM 100, an ASADAL/COMP 200, an ASADAL/OBJ 300, an ASADAL/ASSET DB 400 and an ASAD AL/ ANAL YZER 500. Among the components of the system illustrated in Fig. 1, the ASADAL/FORM 100, the ASADAL/COMP 200, the ASADAL/OBJ 300, the ASAD AL/ ANAL YZER 500 may be implemented by software executable in an independent computer or a plurality of computers connected by a network.

[27] In the system in accordance with the present invention, the ASADAL/FORM 100 performs a feature modeling with respect to a domain and selects a feature corresponding to an application program; the ASADAL/COMP 200 develops an asset component and performs a generation and a configuration management of a software component through a macro-processing; and the ASADAL/OBJ 300 performs an architecture modeling and an operational modeling for an application software development, an automatic code generation and a validation through a construction of a virtual test bed and a simulation. Further, the ASADAL/ASSET DB 400 stores products generated from the aforementioned modules; and the ASADAL/ANALYZER 500 verifies consistency between the products stored in the ASADAL/ASSET DB 400.

[28] Hereinafter, each module included in the ASADAL serving as a system for generating a development framework in accordance with the present invention will be described in detail with reference to the accompanying drawings.

[29]

[30] ASADAL/FORM

[31] Fig. 2 describes a block diagram illustrating a data processing flow and a composition of the ASADAL/FORM 100 of the ASADAL serving as a system for providing a development framework in accordance with the present invention. Main functions of the ASADAL/FORM 100 are to allow a software product line analyzer to generate a domain feature model by analyzing a domain and extracting commonalities and variabilities between related systems on a feature basis and to make an application program developer select by analyzing systems a feature satisfying requirements of an application program. Such functions will be described in detail as follows.

[32] A 'feature' indicates attributes or characteristics within a domain in which anybody concerned with a specific domain may be interested. For example, the feature can be found out by analyzing user manuals, software documents and terminologies used by domain experts. Further, a feature modeling is a process for finding out features indicating commonalities and variabilities between systems in a range of the domain from a number of candidate features and then specifying a relationship and a composition rule thereof. In other words, the feature modeling refers to a process for defining commonalities and variabilities and for clarifying variabilities that may develop in the future between similar systems.

[33] The ASADAL/FORM 100 constructs a feature model by using an editor module for supporting a feature modeling, and thefeature model is stored in the ASADAL/ASSET DB 400 to be used by other modules.In other words, referring to Fig. 2, a product line analyzer 102 obtains candidate features by analyzing a domain (Sl 10) and then constructs a tree-structured feature model by classifying the candidate features into mandatory featuresindicating commonalities between the systems and optional and alternative features indicating variabilities therebetween with a help of a feature model editor (S 120).

[34] The ASADAL/FORM 100 finds out the mandatory features, the optional features or the like showing the commonalities and the variabilities between the systems to specify the relationship therebetween and the composition rule thereof. Further, the ASADAL/ FORM 100 verifies whether or not the featuremodel constructed by the product line analyzer 102 is specified pursuant to the composition rule and whether or not the relationship between the features is properly matched (S 130). Due to the feature model verification process, the product line analyzer 102 can obtain an effective feature model.

[35] The requirements of the application program in the domain can be specified by selecting features corresponding to the application program from the features indicat- ingvariabilities and the mandatory features indicating commonalities in the feature models for the domain.An application program developer selects features, by using the feature selection module of the ASADAL/FORM 100, based on an explanation or a composition rule of the features in the feature model formed by a domain analyzer to thereby generate an effective feature group satisfying the requirements of the application program.

[36] More specifically, referring to Fig. 2, the application program developer 104 analyzes the application program to determine the requirements of the application program (S 140). Thereafter, the application program developer 104 retrieves the feature models stored in the ASADAL/ASSET DB 400 to select features satisfying the requirements (S 150). Such feature selection information is stored in the ASADAL/ ASSET DB 400.

[37]

[38] ASADAL/COMP

[39] Fig. 3 provides a block diagram depicting a data processing flow and functions of the ASADAL/COMP 200 of the ASADAL serving as a system for providing a development framework in accordance with the present invention. Main functions of the ASADAL/COMP 200 include forming a reusable asset component based on the feature model formed by the ASADAL/FORM 100 and the feature selection information, generating a software component suitable for the feature selection by macro-processing the asset component, and performing a configuration management of the software component. [40] Hereinafter, an asset component development process, i.e., one of the main functions of the ASADAL/COMP 200, will be described in detail with reference to Fig. 3.

[41] In order to be reusable in various application programs having a variety of requirements, the asset component needs to be formed such that it can properly deal with a case where the alternative and the optional features indicating the variabilities between the application programs retrieved from the feature models are selected as well as a case where those features are not selected. Further, the asset component defines macros for determining whether or not features usable in forming the asset component are selected and for supporting a removal of unnecessary codes and an insertion of proper codes.

[42] Referring to Fig. 3, in order to form an asset component, the ASADAL/COMP 200 retrieves a feature model constructed for a corresponding domain from the ASADAL/ ASSET DB 400. The ASADAL/COMP 200 defines the asset component for grouping and implementing highly related mandatory features defined by the feature model retrieved from the ASADAL/ASSET DB 400 and also specifies by using the macros the way in which the components deals with a case where the alternative and the optional features related to the asset component are selected as well as a case those features are not selected, if those features exist(S240). Further, the asset component is stored in the ASADAL/ASSET DB 400 to be used for generating a software component.

[43] The ASADAL/COMP 200 defines the macros for determining whether or not features usable in forming the asset component are selected and for supporting the removal of unnecessary codes and the insertion of proper codes, wherein an asset component verification module supports a function of verifying grammatical errors occurred in forming the macros and validity of the specification (S210). A task for an asset component verification is a basic operation of the macro-processing in developing a software component such that it has to be carried out prior to the macro- processing.

[44] As depicted in Fig. 3, the ASADAL/COMP 200 obtains the feature selection information and the asset component retrieved from the ASADAL/ASSET DB 400, processes the macros included in the asset component specification to accord with their meanings based on the feature selection information and the asset component and then automatically generates the software components by removing codes for implementing unselected features and properly changing codes for implementing selected features (S220). Thus generated software components are stored in the ASADAL/ASSET DB 400, and a configuration management module performs a configuration management of the software components and the feature selection information. [45] That is, the configuration management module manages the feature selection information and the asset component information used in generating the software components. Therefore, when any problems are encountered in the software components, the configuration management module provides traceability of the feature model and the asset component and also manages a version of the components (S230).

[46] For example, if the software components formed by the ASADAL/COMP 200 cause problems while being used in external modules, in order to solve the problem, the feature selection information of the software component and the version information of the asset component are provided to a user from the configuration management module of the ASADAL/COMP 200, thereby providing a trace of the software component. By analyzing such information, basic causes of the problems of the software components can be found and, thus, a modified software component can be produced.

[47]

[48]

[49] ASADAL/OBJ

[50] The ASADAL/OBJ 300 functions to design and implement an application program and also verifies the application program through a virtual test-bed simulation. In the ASADAL/OBJ 300, a controller is used to develop an application program for controlling the system, and an environment object is used to develop a virtual environment where the application program is actually embedded and performed.

[51] To be specific, the ASADAL/OBJ 300 uses the software components generated by the ASADAL/COMP 200 based on the requirements of the application program during the design and the implementation of the application program. In the ASADAL/OBJ 300, the software components are presented in behavioral and functional specification languages, and an architecture modeling is provided to indicate a relationshipbetween such components and the software components generated by the ASADAL/COMP 200. Further, the application program validation through the simulation on the virtual test bed is performed through a three dimensional simulation by specifying a virtual environment for testing the application program by using an environment object modeling of the ASADAL/OBJ 300.

[52] Fig. 4 is a block diagram showing a data processing flow and a function of the controller of the ASADAL/OBJ 300 of the ASADAL serving as a system for providing a feature-oriented software reuse development framework in accordance with the present invention.

[53] First of all, in a software architecture modeling module, an application program developer 301 designs how to embed dysfunctional elements of features in a substantial system (S302). In other words, such module determines how to design ar- chitecture for the system by effectively and properly using the operation model and the software components of the ASADAL/ASSET DB 400. Thus generated architecture model is stored in the ASADAL/ASSET DB 400.

[54] Next, the operation modeling module expresses the system by specifying functions and behaviors to be performed in the system (S304).The ASADAL/OBJ 300 is capable of defining the operation modeling by specifying the function and behavior of the inner system referring to the system architecture stored in the ASADAL/ASSET DB 400 and also constructing the system by reusing the software components generated based on the features. Since the ASADAL/OBJ 300 provides a specification enabling to use the software components required for the system's operation, the user can conveniently use external software components. Further, it is possible to reuse another system's operation model having same functions, which is stored in the ASADAL/ASSET DB 400.

[55] In case specifications of the models obtained from each module are highly complicated, the validity of the models is examined by searching for inconsistency of the specification or errors of the models by using a logic analyzer. In the ASADAL/ OBJ 300, the application program developer can reduce the errors that may occur during the automatic code generation and increase the efficiency by verifying the validity of the operation model and the architecture model (S306 and S308).

[56] In the development framework in accordance with the present invention, by inputtingthe operation model retrieved from the ASADAL/ASSET DB 400 into the automatic code generation module, codes can be conveniently produced by target program languages. In other words, by virtue of the automatic code generation module, the user can provide an environment capable of reducing a software development time and solving various problems generated in forming the codes. The ASADAL/OBJ 300 generates a simulation code to be tested by a three dimensional virtual simulation and a target code to be embedded and operated in an actual system (S310 and S312). Accordingly, the simulation code is produced such that it can be simulated with an environment object during the virtual testing process, and the control code is generated such that it can be downloaded and executed in the actual system.

[57] Fig. 5 provides a block diagram illustrating a data processing flow and a function of an environment object of the ASADAL/OBJ 300 of the ASADAL serving as a feature-oriented software reuse development framework in accordance with the present invention.

[58] A main feature of the ASADAL/OBJ 300 is to provide an environment for virtually modeling a system where specific software is embedded and executed. Such environment, which is for testing whether or not the codes generated by the automatic mode generation module can properly operate when they are embedded in the actual system, can virtually model the system where the actual codes are embedded.

[59] Referring to Fig. 5, the environment object modeling module is a three dimensional module in which systems having various shapes are visually represented to model shapes of objects (S314). Such shape model can virtually express a movement of the actual object during the virtual simulation while being matched with the operation model S304 (S310).

[60] Fig. 6 presents a block diagram showing an operation of an I/O mapping of the

ASADAL/OBJ 300 of the ASADAL serving as a feature-oriented software reuse development framework in accordance with the present invention. In the ASADAL/OBJ 300, it is possible to perform a virtual I/O mapping S316 for connecting data and events between the controller and the environment object and an actual I/O mapping S318 for connecting data and events between the actual system and the environment object. A simulation module of the ASADAL/OBJ 300 is provided with an I/O mapping table module for connecting data and events between a control code and the environment object, so that the control code and the environment object can be supported to be simulated together.

[61] Referring to Fig. 7, in order to testthe application program obtained from the architecture modeling and the operation modeling, the ASADAL/OBJ 300 produces an environment in which the application program is to be embedded in an environment modeling module, and then arranges the I/O mapping module in the middle of the architecture modeling and the operation modeling to map the data and the events therebetween. That is, in the ASADAL/OBJ 300, the application program developer models the controller and the environment object and then connects them with the I/O mapping module for mapping the events and the data therebetween for the simulation (S320 to S324). Further, the ASADAL/OBJ 300 includes a controller simulation module (or engine) and an environment simulation module (or engine) for generating and simulating executable simulation codes by inputting the inner specification of the controller and the environment object. In the ASADAL/OBJ 300, the I/O handling module controls an exchange of the data and the events between the engine for simulating the control code and the engine for simulating the environment, so that a software testing process can be visually and intuitively performed. Due to the intuitive testing, the user can check whether or not the control code can properly operate when it is actually embedded and also can quickly respond to cope with anticipated problems in the system.

[62] Fig. 8 presents a block diagram depicting a simulation between the actual system and the ASADAL/OBJ 300 of the ASADAL serving as a system for providing a feature-oriented software reuse development framework. Referring to Fig. 8, in the ASADAL/OBJ 300, a target code is downloaded from the ASADAL/ASSET DB 400 to an actual system 330 and, then, an actual I/O mapping module S326 is positioned between the actual system 330 and a virtual environment simulation S328 to map data and events therebetween. Therefore, the actual system can test the data and the events to be sent to an actual object beforehand in a virtual environment, which enables to test whether or not the code can properly operate before it is embedded in the actual system, thereby reducing a testing cost.

[63] Fig. 9 is a block diagram illustrating a composition of the ASAD AL/ ANAL YZER

500 of the ASADAL serving as a system for providing a feature-oriented software product line development framework in accordance with the present invention. The ASAD AL/ ANAL YZER 500 in accordance with the present invention serves to verify consistency between models stored in the ASADAL/ASSET DB 400 and check validity of the specification of the corresponding models. More specifically, an asset developer can verify the consistency between the feature model and the asset component (S330), and the application program developer can verify inner consistency of the operation model, consistency between the architecture model and the software component, and consistency between the software component and the operation model (S332 to S336). Such a model checking function is essentially performed during the design and the code generation. Accordingly, without the model checking, it is hard to guarantee an accurate operation of the automatically generated code.

[64] Hereinafter, specific functions supported by the aforementioned ASADAL framework will be described by using the preferred embodiments provided in terms of (1) asset development, (2) application development, (3) application testing, and (4) application maintenance.

[65]

[66] First preferred embodiment: asset development

[67] The following is a description of a method for developing an asset component by using the aforementioned modules of the ASADAL in accordance with the present invention.

[68] In other words, the ASADAL framework basically analyzes a system based on features. Thus, before the asset component is developed, candidate features are obtained by analyzing commonalities and variabilities of the domain and, then, a complete feature model is constructed by using a feature modeling module of the ASADAL/FORM 100 (see Sl 10 and S 120 in Fig. 2). After the validity of the feature model itself is verified, the verified feature model is stored in the ASADAL/ASSET DB 400 (see S 130 in Fig. 2).

[69] In the ASADAL/COMP 200, an asset component is specified by using macros so that it can properly deal with a selectivity of mandatory features fully affecting the component, optional features partially affecting the component and alternative components alternatively affecting the component in the feature model obtained by the domain analysis (see S240 in Fig. 3). The obtained asset component is stored in the ASADAL/ASSET DB 400 after the validity thereof is verified by the asset component verification module (see S210 in Fig. 3).

[70] The asset developer verifies whether or not the asset component formed based on a feature basis is consistent by using the AS AD AL/ AN AL YZER 500 (see Fig. 9).

[71]

[72] Second preferred embodiment: application development

[73] If the development of the asset component for the domain is completed, the application program developer exclusively selects features satisfying system requirements from the feature model (see S 140 and S 150). The feature selection is performed by the ASADAL/FORM 100, and the feature selection information is stored in the ASADAL/ASSET DB 400.

[74] In the ASADAL/COMP 200, the feature selection information and the asset component are retrieved from the ASADAL/ASSET DB 400, and then, the macro- processing for properly matching the feature selection information with the asset component is performed to generate a software component (see S220 in Fig. 3). In other words, by macro-processing the feature selection information selected based on the user requirements, a software component completed by exclusively applying the codes for implementing the selected features is generated. Thus generated software component is managed by the configuration management module in the ASADAL/ COMP 200 and also stored in the ASADAL/ASSET DB 400 to be reused by an external module (see S230 in Fig. 3).

[75] Once the software component is generated as described above, an application program is formed by using a reusable component. At this time, the ASADAL/OBJ 300 for supporting the architecture modeling, the operation modeling and the automatic code generation is used. In other words, the ASADAL/OBJ 300 designs an architecture model satisfying the user requirements based on various reusable models stored in the ASADAL/ASSET DB 400 (see S302 in Fig. 4). Further, in the ASADAL/ OBJ 300, an inner operation model of the system is specified in terms of inner functions and behaviors of the system (see S304 in Fig. 4). The functional specification enables the use of an external software component, so that the system can be formed by reusing the software component. Moreover, the validity of the formed architecture model and the operation model can be verified by the validity verificationmodule (see S306 and S308 in Fig. 4).

[76] The operation module generated by the ASADAL/OBJ 300 is inputted into the automatic code generation module, thereby automatically generating an executable target code and simulation code (see S310 and S312 in Fig. 4).Thus obtained simulation code makes the controller engage with the environment object in a virtual environment,and the target code performs a control function after being downloaded to the actual system. The executable codes automatically generated by the ASADAL/OBJ 300 are used during the application program testing process and then stored in the ASADAL/ASSET DB 400.

[77]

[78] Third preferred embodiment: application testing

[79] The application testing process includes (i) a virtual simulation using a simulation code and an environment object and (ii) a testing of a target code downloaded to the actual system.

[80] Above all, in the testing using a virtual environment simulation, a virtual environment where a program is embedded and executed is specified by the environment modeling module of the ASADAL/OBJ 300 (see S314 in Fig. 5). The data and the events between the codes of the controller and the environment objects are mapped by the virtual I/O mapping module, and then, such mapping information is stored in the ASADAL/ASSET DB 400 (see step S316 in Fig. 6). Next, the ASADAL/OBJ 300 can intuitively test the control software for controlling the system by using a three dimensional simulation module for embedding and testing the control software in a virtual environment and further can check whether or not the automatically generated codes properly operate as intended in the virtual environment (see S320 to S324 in Fig.

7).

[81] If the executable codes are verified by the virtual environment testing, there is a need to verify whether or not the executable codes properly operate after being downloaded to the actual system. Since the ASADAL/OBJ 300 has the actual I/O mapping information enabling the actual system and the virtual simulation environment to mutually exchange the data and the events, it is possible to verify whether or not the executable codes properly operate (see S326 in Fig. 8).

[82]

[83] Fourth preferred embodiment: application maintenance

[84] In case where a test result of virtual simulation performed in the ASADAL/OBJ 300 is different from an expectation, errors generated in the software components can be corrected by following methods.

[85] (1) First of all, it is considered whether or not the feature model itself needs to be corrected. In this case, the correction can be performed by the ASADAL/FORM 100. Thus corrected feature model is stored in the ASADAL/ASSET DB 400, and the software component is regenerated by the ASADAL/COMP 200.

[86] (2) In case the feature model does not need a correction, it is checked whether or not the asset component needs to be corrected. If the asset component needs a correction, it is corrected by the ASADAL/COMP 200 and then stored in the ASADAL/ASSET DB 400. Further, the software component is regenerated by the ASADAL/COMP 200.

[87] (3) In case the feature model and the asset component do not need a correction, an inner specification is corrected by the operation modeling module in the ASADAL/ OBJ 300.

[88] After the problems encountered in the software component are discovered by the aforementioned methods, the ASADAL/OBJ 300 tests the codes corrected by the code automatic generation in a virtual environment, thereby enabling to develop the software.

[89] While the invention has been shown and described with respect to the preferred embodiments, it will be understood by those skilled in the art that various changes and modification may be made without departing from the scope of the invention as defined in the following claims.

[90]

Claims

[1] A system for providing a feature-oriented software product line development environment, comprising: an ASADAL/FORM for performing a feature modeling in a specific domain and selecting a feature corresponding to an application program from features generated by the feature modeling; an ASADAL/COMP for developing an asset component based on feature selection information, producing and performing a generation of a software component through the use of a macro-processing and a configuration management of the software component; an ASADAL/OBJ for performing an architecture modeling and an operation modeling necessary to develop an application software, an automatic code generation, an establishment of a virtual test bed and a validation through a simulation thereof; an ASADAL/ASSET DB for storing therein data generated by the ASADAL/ FORM, the ASADAL/COMP and the ASADAL/OBJ; and an ASAD AL/ANAL YZER for verifying consistency between the data stored in the ASADAL/ASSET DB.

[2] The system of claim 1, wherein the ASADAL/FORM includes: a feature modeling editor for constructing a tree-structured feature model by classifying candidate features obtained from the domain analysis into mandatory features showing commonalities between systems related with the domain, optional and alternative features showing variabilities between the systems; a feature model verification module for verifying whether or not a relationship of the features and a composition rule of the feature model are specified; and a feature selection module for selecting an effective feature satisfying requirements of the application program based on an explanation and a composition rule of the features in the feature model.

[3] The system of 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/ASSET DB.

[4] The system of claim 1, wherein the ASADAL/COMP includes: an asset component development module for specifying by using macros the way an asset component deals with the optional and the alternative features in the feature model; an asset component verification module for verifying grammatical errors occurred in forming the macros and validity of the specification; a software component generation module for automatically generating a software component while changing codes for implementing selected features by proce ssingthe macros included in the asset component specification based on the feature selection information; and a component configuration management module for managing configuration management information formed based on the asset component information and the feature selection information used in generating the software componentand for providing traceability of the feature model and the asset component in case of encountering problems in the software component.

[5] The system of claim 4, wherein the asset component development module generates the asset component by using the feature model transferred from the ASADAL/ASSET DB and then stores the generated asset component in the ASADAL/ASSET DB; wherein the software component generation module generates the software component by using the asset component and the feature selection information transferred from the ASADAL/ASSET DB and then stores the generated software component in the ASADAL/ASSET DB; and wherein the configuration management information generated by the configuration management module is stored in the ASADAL/ASSET DB.

[6] The system of claim 1, wherein the ASDADL/OBJ includes: a software architecture modeling module for generating a software architecture by designing how to embed dysfunctional elements of a feature expressed in the feature model in an actual system; an operation modeling module for generating an operation model expressing the system by specifying functions and behaviors of the system referring to the software architecture; a model validity verification module for verifying inconsistency and errors of the specification included in the software architecture and the operation model generated by the software architecture modeling module and the operation modeling module; and an automatic code generation module for generating a control code and a simulation code with a target program language by using the functional and the behavioral specification obtained based on the operation model.

[7] The system of claim 6, wherein the ASADAL/OBJ further includes: an environment object modeling module for generating an environment object by virtually modeling a system where the application program is embedded 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 in the environment object; a virtual I/O mapping module for connecting data and events transceived between the controller simulation module and the environment simulation module; and an actual I/O mapping module for connecting data and events transceived between the system and the environment simulation module.

[8] The system of claim 7, wherein the environment object modeling module generates a three dimensional module for visually indicating systems having various shapes to model a shape of the environment object, and wherein the environment simulation module carries out a three dimensional simulation by matching the three dimensional model with the operation model.

[9] The system of claim 7, wherein the target code is downloaded from the system to the controller of the actual system, and wherein the system carries out a simulation by performing a communication of events and data between the actual I/O mapping module and the environment simulation module.

[10] The system of claim 6, wherein the operation modeling module uses a reusable software component inputted from an outside of the system through a functional specification.

[11] The system of claim 6, wherein the software architecture modeling module stores the generated software architecture in the ASASAL/ASSET DB, and wherein the operation modeling module generates the operation model by using the software architecture transferred from the ASADAL/ASSET DB and then stores the generated operation model in the ASADAL/ASSET DB.

[ 12] The system of claim 1 , wherein the AS AD AL/ANALYZER includes : a module for examining consistency between the feature model and the asset component; a module for examining consistency of the operation model; a module for examining consistency between the architecture model and the software component; and a module for examining consistency between the software component and the operation model.