KR20230014420A - Software that can provide optimized configurations for systems based on dynamically changing information at run time - Google Patents

Abstract

Disclosed are an autonomous management providing method of a software system capable of providing an optimized system in response to an environment changing in real time, a recording medium storing a program performing the same, and a system with an autonomous management function of software. When a service is requested from a user, all configurations of a system capable of providing the requested service are acquired from a dynamic feature model. A configuration corresponding to the requested service among all the acquired configurations of the system is acquired based on a preset policy to reconstruct resources of the system, and the requested service is provided based on the reconstructed resources. Therefore, an optimized service can be provided in response to an environment changing in real time without intervention of a user.

Description

Method for providing self-management of a software system capable of providing optimized configuration for a system based on information that dynamically changes during execution

The present invention relates to a software development method, and more particularly, to a method for providing autonomous management of a software system capable of providing an optimized configuration for a system based on information that dynamically changes during execution, and a record of a program executing the same. It relates to a system having a self-management function of media and software.

Product Line Engineering (PLE) is an approach that provides an effective way to quickly develop various specialized software in the same domain by applying systematic reuse techniques when developing software. It is a methodology to develop software of the same product line in a short time by analyzing and extracting the similarities and differences of various applications belonging to one area, and defining reusable product line assets based on this.

Among the methods for product line engineering, the feature-oriented software development method proposed by CMU SEI in 1990 is the most widely used. In the feature-based software development method, a domain expert analyzes the commonalities and differences of products on a feature-by-feature basis and defines a feature model, and an application program developer develops a new product in a short time based on the defined feature model. It is a way to develop within.

Specifically, in the conventional feature-based software development method, after a domain expert analyzes a product line, a product line reuse library is created based on the analyzed product line, and this is converted into a feature model. use to define relationships. In addition, the application engineer easily developed new software to meet the requirements of the software system based on the feature model.

However, the above-described conventional feature-based software development method has the advantage of effectively using software development time and economic cost. When the system is running, it is impossible to provide an optimized system that dynamically responds to a changing environment in real time, and thus, a user's intervention is required.

An object of the present invention is to provide a method for providing autonomous management of a software system capable of providing an optimized system corresponding to a changing environment in real time.

Another object of the present invention is to provide a recording medium on which a program for performing the method for providing self-management of the software system is recorded.

In addition, another object of the present invention is to provide a system equipped with a software self-management function capable of providing an optimized system corresponding to a real-time changing environment.

The technical problems of the present invention are not limited to the technical problems mentioned above, and other technical problems not mentioned will be clearly understood by those skilled in the art from the following description.

A method for providing autonomous management of a software system according to an aspect of the present invention for achieving the above object of the present invention includes receiving a service request from a user, and providing the requested service from a dynamic feature model. Acquisition of all configurations of a system capable of performing the service; acquiring a configuration corresponding to the requested service among all configurations of the acquired system based on a preset policy; and based on the obtained configuration. and reconfiguring system resources and providing the requested service based on the reconfigured resources. The dynamic feature model may represent a configuration of objects that can operate when the software system runs. The dynamic feature model may include a runtime feature that defines values that change during execution of a system in which a software system is installed. Acquiring a configuration corresponding to the requested service based on a preset policy from among all the acquired configurations of the system may include: among all the acquired configurations of the system based on the runtime feature of the system. You can obtain the most suitable configuration for the requested service. The method for providing self-management of the software system may, prior to the step of obtaining a configuration corresponding to the requested service among all configurations of the acquired system based on the preset policy, from the system or a surrounding physical environment. The step of obtaining context information may be further included. Acquiring a configuration corresponding to the requested service among all configurations of the acquired system based on the preset policy may include all configurations of the acquired system based on the preset policy and the acquired context information. Among them, a configuration corresponding to the requested service may be obtained.

In addition, a recording medium recording a program for performing a method for providing self-management of a software system according to an aspect of the present invention for achieving the other object of the present invention described above includes all components of the system capable of providing the requested service ( configuration from a dynamic feature model, obtaining a configuration corresponding to the requested service among all configurations of the acquired system based on a preset policy, and A program performing the step of reconfiguring system resources based on the reconfiguration and the step of providing the requested service based on the reconfigured resources is recorded.

In addition, a system having a software self-management function according to an aspect of the present invention for achieving another object of the present invention provides a dynamic feature model that provides all configurations of a system capable of providing requested services. and an autonomous manager providing a configuration corresponding to the requested service among all configurations of the acquired system based on preset policy information and a configuration for the service requested from the autonomous manager, and receiving the provided and a core system that reconfigures system resources based on the configuration and then provides services to users based on the reconfigured resources. The system having the software self-management function receives a policy set by a user and provides the provided policy or a target corresponding to the provided policy to the self-administered policy manager and the system or the surrounding physical environment. It may further include a context manager that collects context information and provides the collected context information to the autonomous manager. The autonomous manager may provide a configuration corresponding to the requested service among all configurations of the acquired system based on the preset policy information and the context information. The dynamic feature model may include runtime features that define values that change when the system runs. The autonomous manager may provide a configuration corresponding to the requested service among all configurations of the acquired system based on the running features of the system.

According to the above-described method for providing self-management of a software system and a system having a self-management function of software according to the present invention, the software system is not only statically configured but also shows an environment that changes in real time while the system is running. A configuration optimized for the requested service is extracted using a dynamic feature model including runtime features, and a service is provided after reconstructing system resources using the extracted configuration.

Therefore, it is possible to provide optimized services corresponding to the changing environment in real time without user intervention, and because of these characteristics, it is suitable for embedded systems, rockets, military software systems, etc. that require a software system that can be dynamically reconfigured according to the required purpose. can be utilized

Since the present invention can make various changes and have various embodiments, specific embodiments will be illustrated in the drawings and described in detail in the detailed description. However, this is not intended to limit the present invention to specific embodiments, and should be understood to include all modifications, equivalents, or substitutes included in the spirit and scope of the present invention. Like reference numerals have been used for like elements throughout the description of each figure.

Terms such as first and second may be used to describe various components, but the components should not be limited by the terms. These terms are only used for the purpose of distinguishing one component from another. For example, a first element may be termed a second element, and similarly, a second element may be termed a first element, without departing from the scope of the present invention. The terms and/or include any combination of a plurality of related recited items or any of a plurality of related recited items.

When a component is referred to as being "connected" or "connected" to another component, it means that it may be directly connected or connected to the other component, but other components may exist in the middle. It should be understood. On the other hand, when a component is referred to as “directly connected” or “directly connected” to another component, it should be understood that no other component exists in the middle.

Terms used in this application are only used to describe specific embodiments, and are not intended to limit the present invention. Singular expressions include plural expressions unless the context clearly dictates otherwise. In this application, the terms "comprise" or "having" are intended to indicate that there is a feature, number, step, operation, component, part, or combination thereof described in the specification, but one or more other It should be understood that it does not preclude in advance the possibility of the presence or addition of features, numbers, steps, operations, components, parts, or combinations thereof.

Hereinafter, with reference to the accompanying drawings, preferred embodiments of the present invention will be described in more detail. Hereinafter, the same reference numerals are used for the same components in the drawings, and redundant descriptions of the same components are omitted.

1 is a block diagram showing the configuration of a system for performing self-management of software according to an embodiment of the present invention. Referring to FIG. 1, a domain engineer analyzes a product line, creates a Product Line Reuse Library 110 based on this, and creates a static feature model (Static Feature Model). ) (120) is used to indicate the relationship.

An application engineer develops software corresponding to the requirements of a corresponding software system to be developed based on the static feature model 120.

Domain experts also create a Dynamic Feature Model 130 for decision making for product reconfiguration at the time of execution of the core system 140 . Here, the static feature model 120 and the dynamic feature model 130 may be created during development of a software system.

In the method for providing self-management of a software system according to an embodiment of the present invention, a conventional feature model is named a static feature model 120 by extending a conventional feature-based software development method, and based on the static feature model, The features that can be changed during execution of the software system are analyzed and the dynamic feature model 130 is newly defined based on the analyzed features.

The dynamic feature model 130 is a model that can define all the configurations in which the core system 140 operates in execution, and how the selected function is executed based on the function selected in the static feature model 120. It defines whether it is activated.

The core system 140 includes both hardware in a predetermined area and a software system installed in the hardware to control the operation of the hardware, receiving a new service request from a user, and providing service request information to an autonomous manager ( 140) is provided. Thereafter, the core system 140 receives configuration information for the requested service from the autonomic manager 150, reconfigures system resources based on the provided configuration information, and then reconfigures system resources based on the reconfigured system resources. provide services to

The autonomic manager 150, based on the policy information provided from the policy manager 160 and the context information provided from the context manager 170, provides all possible features of the core system 140 provided from the dynamic feature model 130. After extracting the most suitable configuration for the service requested by the user from the configuration information, it is provided to the core system 140 .

The policy manager 160 receives a higher-level policy from the user and provides the provided policy or a specific goal corresponding to the higher-level policy to the autonomous manager 150.

The context manager 170 collects context information that can be provided from the core system and/or the surrounding physical environment, and provides the collected context information to the autonomic manager 150 .

2 is a flowchart illustrating a method for autonomous management of a software system according to an embodiment of the present invention.

Referring to FIGS. 1 and 2, a method for autonomous management of a software system according to an embodiment of the present invention is described. First, the core system 140 receives a service request from a user (step 210), and receives a service request from a user (step 210). Service request information is provided to the autonomic manager 150 .

The autonomic manager 150 obtains policy information set by the user from the policy manager 160 (step 220) and obtains context information from the core system and/or surrounding physical environment from the context manager 170 (step 220). 230).

In addition, the autonomous manager 150 obtains all possible configuration information of the system from the dynamic feature model (step 240), and based on the obtained policy information and situation information, among all possible configuration information of the system, the service requested by the user is selected. After extracting the most suitable configuration (step 260), the extracted configuration information is provided to the core system 140.

The core system 270 reconfigures system resources based on configuration information provided from the autonomic manager 150 (step 260) and provides a service requested by the user using the reconfigured resources (step 270).

In FIG. 2, after a service request is received (step 210), policy information set by the user is obtained (step 220) and situation information is obtained (step 230) as an example, but this is for convenience of explanation. However, in practice, steps 210 to 230 may be performed in reverse order. In addition, the execution order of step 220 and/or step 230 may be changed from that of step 240.

3 is a conceptual diagram illustrating the relationship between a static feature model and a dynamic feature model applied to a method for self-management of a software system according to an embodiment of the present invention.

Referring to FIG. 3, the upper cone region in FIG. 3 represents a static feature model for software system development, and the lower cone region represents a dynamic feature model that can be reconstructed during execution of a product. .

In FIG. 3 , P1, P2, P3, and P4 denote programs, and f1, f2, f3, and f4 denote static features. Also, C1, C2, C3, and C4 mean configuration, and f1' and f2' mean dynamic features.

The static feature model can gradually develop P2, P3 and P4 from the basic software program P1 using features. For example, assuming that P1 is a calculator program having only an addition function, f1 is a subtraction function, and f2 is a division function, P4 is a calculator program having addition, subtraction, and division functions.

The dynamic feature model represents the configuration in which the software system created as described above will operate while it is being executed. That is, if a feature is a program code in a static feature model, it becomes an object for it in a dynamic feature model. For example, while the software system is running, program P4 may become C1 consisting only of addition based on policy and situation information, or may be reconstructed into any one of C2, C3, and C4 with addition of subtraction and/or division functions. . In addition, the configurations of C1, C2, C3, and C4 may be changed by adding or excluding dynamic features according to policies and situation information.

4 shows a comparison between a static feature model and a dynamic feature model applied to a method for self-management of a software system according to an embodiment of the present invention.

Referring to FIG. 4 , the static feature model is for synthesizing a software program, and the dynamic feature model is a decision-making model for reconstruction while the system is running.

In addition, static feature models and dynamic feature models are created by domain engineers (or domain experts) at the time of software development, static feature models are decisions made by software developers at the time of software system development, and dynamic feature models are It is determined by the autonomous administrator or user at run time.

If the combination of features in the static feature model is a software system, the combination of features in the dynamic feature model becomes the running state (or configuration) of the system. If the software system during system operation is expressed as a Finite State Machine (FSM), the state is an independent state, so it can be said that it is like this.

5 is a conceptual diagram illustrating the configuration of a static feature model of a mobile communication terminal for explaining an example to which a method for self-management of a software system according to an embodiment of the present invention is applied.

Software installed in mobile communication terminals is a very suitable case to apply product line engineering because various functions should be provided corresponding to the various hardware provided in mobile communication terminals.

A feature model is a domain analysis model that charts the commonalities and differences of various systems in an domain as an AND/OR graph as a means of communication between experts and general users or developers in the domain. In the feature model, common features within a domain are expressed as mandatory features, and distinct differences between systems are expressed as optional features, alternative features, and OR features that allow one or more choices. do.

Referring to FIG. 5, a static feature model of a mobile communication terminal is described. In a mobile communication terminal, an application is an essential feature, and a video call is an optional feature in the application. A mobile communication terminal may include an application, may have a network interface, and may also have a policy. In this case, a new mobile communication terminal system can be created by adding applications, network interfaces, and policies based on the relationship of the feature model given to the base mobile communication terminal.

In the static feature model of the mobile communication terminal shown in FIG. 5, the application must include a voice call, and at least one network interface and policy among CDMA, WLAN, WiBro, and Bluetooth. (policy).

6 is a conceptual diagram illustrating the configuration of a dynamic feature model of a mobile communication terminal for explaining an example to which a method for self-management of a software system according to an embodiment of the present invention is applied.

Referring to FIG. 6 , static feature models are generated by analyzing functional characteristics of products, whereas dynamic feature models are generated by analyzing characteristics of a running system. For example, in the static feature model of the mobile communication terminal shown in FIG. 5, a software developer selects a voice call and a web browser as applications and uses them as network interfaces. Assuming that CDMA, WLAN, and WiBro are selected, and RSS (Received Signal Strength), COST, POWER, QUALITY, and MANUAL are selected as network interface selection methods, the mobile communication terminal includes all of the above functions. It is manufactured by

A dynamic feature model represents how a system can change during execution. For example, looking at the dynamic feature model of the mobile communication terminal shown in FIG. 6, while the current mobile communication terminal is running, applications are not running or voice calls and web browsers Only one of these can be executed, the network interface cannot be activated, or only one of CDMA, WLAN, and WiBro can be activated, and the policy is RSS, Cost, Power, Quality, and Manual. It can be seen that only one can be selected.

In a mobile communication terminal having a dynamic feature model as shown in FIG. 6, an autonomous manager manages a system according to a corresponding policy set based on the dynamic feature model. For example, an autonomous manager may select an optimal network interface based on a policy set for each application.

In the dynamic feature model, as a new feature that is not in the static feature model, values that can change during execution are defined as runtime features. In FIG. 6, in the case of a network interface, availability, signal strength, cost model, power consumption rate, quality, etc. Indicates a changeable feature, and the autonomous manager selects an optimal network interface by using the feature during execution while the mobile communication terminal is running. For example, in a place where CDMA cannot be used, the availability of CDMA becomes F (False), and the autonomous manager selects the most appropriate network interface using the values of these runtime features. do.

FIG. 7 is a state diagram of a mobile communication terminal self-managed based on the dynamic feature model of the mobile communication terminal shown in FIG. 6 .

Referring to FIG. 7, when the power is turned on, the mobile communication terminal transitions from a power-off state to a power-on state, and operates in a standby state (S1, IDLE) in the power-on state. start

Thereafter, the mobile communication terminal transitions to a voice call (S2) state or a web browser (S3) state according to the user's manipulation.

As described above, when the state is transitioned and a voice call or a web browser is used, the network interface is activated. Here, in the initial stage when the network interface is used, the user directly selects one of CDMA, WLAN, and WiBro, and then the mobile communication terminal uses a dynamic feature model-based runtime feature and a preset policy. The optimal network interface is autonomously selected based on policy and/or collected context information.

For example, assuming that the user selects voice call (S2) in the standby state (S1) of the mobile communication terminal and initially selects WiBro (S6) as the network interface, the autonomous manager of the mobile communication terminal During execution, the network interface may be selected as the WLAN (S5) autonomously at a predetermined time based on a changing runtime feature and a policy previously set by the user.

In the above, the present invention has been described in detail with preferred embodiments, but the present invention is not limited to the above embodiments, and various modifications and changes are made by those skilled in the art within the technical spirit and scope of the present invention. this is possible

Claims (12)

receiving a service request from a user;
obtaining all configurations of a system capable of providing the requested service from a dynamic feature model;
obtaining a configuration corresponding to the requested service among all configurations of the acquired system based on a preset policy;
reconfiguring system resources based on the acquired configuration; and
and providing the requested service based on the reconfigured resource. The method of claim 1, wherein the dynamic feature model is
A method for providing self-management of a software system, characterized in that the software system represents a configuration of objects that can operate at runtime. The method of claim 1, wherein the dynamic feature model is
A method for providing self-management of a software system, wherein a system in which the software system is installed includes a runtime feature defining values that change during execution. The method of claim 3, wherein acquiring a configuration corresponding to the requested service based on a preset policy among all the acquired configurations of the system comprises:
and acquiring a configuration most suitable for the requested service among all configurations of the acquired system based on the runtime feature of the system. The method of claim 1, wherein the method for providing self-management of the software system comprises:
Prior to the step of acquiring a configuration corresponding to the requested service among all configurations of the acquired system based on the preset policy, acquiring context information from the system or a surrounding physical environment A method for providing self-management of a software system, further comprising: The method of claim 5, wherein acquiring a configuration corresponding to the requested service among all configurations of the acquired system based on the preset policy comprises:
and obtaining a configuration corresponding to the requested service among all configurations of the acquired system based on the preset policy and the acquired context information. In a recording medium in which a program of instructions that can be executed by a digital processing device performing self-management of software is tangibly implemented and a program that can be read by the digital processing device is recorded,
obtaining all configurations of a system capable of providing the requested service from a dynamic feature model;
obtaining a configuration corresponding to the requested service among all configurations of the acquired system based on a preset policy;
reconfiguring system resources based on the acquired configuration; and
A recording medium recording a program for performing the step of providing the requested service based on the reconstructed resource. a dynamic feature model that provides all configurations of a system capable of providing requested services; Corresponding to the requested service among all configurations of the acquired system based on preset policy information
is an autonomous manager providing configuration; and
A software self-management function including a core system that receives a configuration for a service requested from the autonomous manager, reconfigures system resources based on the provided configuration, and then provides a service to a user based on the reconfigured resources A system equipped with. The method of claim 8, wherein the system having the software self-management function,
a policy manager that receives a policy set by a user and provides the provided policy or a goal corresponding to the provided policy to the autonomous manager; and
The system having a software self-management function, characterized in that it further comprises a context manager for collecting context information from the system or a surrounding physical environment and providing the collected context information to the autonomous manager. 10. The method of claim 9, wherein the autonomous manager
and providing a configuration corresponding to the requested service among all configurations of the acquired system based on the preset policy information and the situation information. 9. The method of claim 8, wherein the dynamic feature model is
A system with a software self-management function, characterized in that the system includes a runtime feature defining values that change during execution. 12. The method of claim 11, wherein the autonomous manager
and providing a configuration corresponding to the requested service among all the configurations of the acquired system based on the running feature of the system.