CN109656539B

CN109656539B - Software self-adaptive transformation method based on object-oriented programming

Info

Publication number: CN109656539B
Application number: CN201811349803.2A
Authority: CN
Inventors: 陈滨; 王兴起; 杜厚旺; 魏丹; 方景龙
Original assignee: Hangzhou Dianzi University
Current assignee: Hangzhou Dianzi University
Priority date: 2018-11-14
Filing date: 2018-11-14
Publication date: 2021-12-14
Anticipated expiration: 2038-11-14
Also published as: CN109656539A

Abstract

The invention discloses a software self-adaptive transformation method based on object-oriented programming; the invention carries out self-adaptive modification on software by applying design modes such as a strategy mode, a proxy mode and the like in object-oriented programming and the idea of extracting service logic in AOP (aspect-oriented programming). The self-adaptive software obtained by transformation can respond to self attribute and complex environment change, and brings great convenience for software maintenance due to the fact that the transformation is based on an object-oriented design concept.

Description

Software self-adaptive transformation method based on object-oriented programming

Technical Field

The invention belongs to the field of software design methods of software engineering, and particularly relates to a software self-adaptive transformation technology based on object-oriented programming.

Background

The software self-adaptive technology is a software design technology which is provided for reducing the software maintenance pressure and enhancing the self fault-tolerant and change-coping capabilities of the software, and the software constructed by the software self-adaptive technology has the self-adaptive capability to the environment and the requirement change, and the software is called self-adaptive software. The self-adaptive software follows a self-adaptive loop of monitoring, analyzing, planning and executing in the running process, and is characterized in that: the self-adaptive software collects and analyzes context information in real time in the running process, and executes self-adaptive behaviors by referring to corresponding strategies in the knowledge base. Context represents an ordered sequence of attributes that are created when an object is activated, and context information contains context events, context states, and context constraints. The knowledge base is a set of a plurality of groups of strategies and provides basis for decision making of the self-adaptive software, the strategy is a language based on an ECA rule and used for indicating the self-adaptive software to adjust behavior opportunity and mode, and the ECA rule is an action triggering rule which is triggered by an event, meets judgment conditions and executes actions. The self-adaptive behavior refers to a process of self-adjusting parameters, structures or behaviors of self-adaptive software through dynamic reconfiguration, namely a process of changing self-code structures or attributes of the self-adaptive software in the running process.

When the software self-adaptive technology is applied and the existing software is subjected to self-adaptive transformation, the main technical difficulty is to realize the dynamic reconfiguration of the non-self-adaptive software. When the traditional adaptive technology realizes the dynamic reconfiguration of software, two main ways exist: the first approach, which tends to directly modify the source code of existing software to match it to a middleware system, requires a developer to have a thorough understanding of the source code of non-adaptive software, fully understand the functional role of the code, and takes a long time. The second approach tends to modify the middleware system to match it with non-adaptive software, which relies on the open-source middleware system, thus limiting the application range and having poor flexibility. Both the two modes depend on a middleware system, the middleware system is various in types, complex in configuration and large in influence on the whole system in use. Middleware is a common service between a platform and an application, which services have standardsProgram interfaceAnd the middleware system is adopted to manage the running process of the existing software, so that the self-adaptive transformation of the software system can be realized. The JBOSS middleware system has excellent response speed and supports AOP expansion, software for self-adaptive transformation by using the JBOSS middleware system has high modularization and loose coupling, but due to a complex configuration mode, developers are required to invest a large amount of time and energy, so that the JBOSS middleware is bloated and troublesome when the JBOSS middleware is used for self-adaptive transformation of light-weight software. The JMS middleware system accesses and manages the receiving and sending of the messages by providing a standard interface for generating, sending and receiving the messages, and software which applies the JMS middleware system for self-adaptive transformation has the characteristics of loose coupling and asynchronization, but the JMS application range is small, and the JMS does not consider the development environment except JAVA at present. AOP, i.e., section-oriented programming, is performed byPrecompilationA mode and operation period dynamic proxy realizes a standard of unified maintenance of program functions, and can isolate each part of service logic by using AOP technology, thereby enabling the service logic to be between each partDegree of couplingThe reusability of the program is reduced, and the development efficiency is improved.

Disclosure of Invention

The invention aims to overcome the defects of the prior art and provide a software self-adaptive transformation technology based on object-oriented programming. The invention carries out self-adaptive modification on software by applying design modes such as a strategy mode, a proxy mode and the like in object-oriented programming and the idea of extracting service logic in AOP (aspect-oriented programming).

The invention relates to a software self-adaptive transformation method based on object-oriented programming, which specifically comprises the following steps:

the method comprises the following steps: constructing a knowledge base and providing a storage structure of a plurality of groups of strategies;

the storage structure of the multiple groups of strategies comprises a class corresponding to a context event, a class corresponding to a context state, a class corresponding to a context constraint, a class corresponding to a constraint element or a logical relationship, a class corresponding to a strategy condition, a class corresponding to an adaptive behavior, a class corresponding to a strategy and a class corresponding to a strategy group;

step two: combing the service logic of the original software system, and organizing corresponding strategies according to the needs;

the original business logic of the software to be modified is combed, the self-adaptive software requirements are determined, the requirements are abstractly expressed into an event Ce, a state Cs, constraint Cr, adjustment Ac and a strategy described according to an ECA rule form;

step three: giving out strategy details, normalizing the strategy details and storing the strategy details in an xml file form;

according to the method, a context event corresponds to an event Ce, a context state corresponds to a state Cs, a context constraint corresponds to a Cr, the attribute provided by the adaptive behavior corresponding to Ac is stored according to a knowledge base, strategies are refined and normalized, and the strategies are stored in an xml file;

step four: separating and extracting the service logic of the original software system as required, and packaging the service logic into a target object;

repackaging the service logic of the original software system by using a proxy mode in object-oriented programming to obtain a target object;

step five: unifying the interfaces of the target object to form a self-adaptive component;

step six: designing a connector, and initializing the attribute direction of the connector to form a self-adaptive module; the adaptive module comprises a connector and a plurality of adaptive components connected with the connector;

the connector has two attributes pointing to the adaptive components, wherein one is used for coordinating the operation method of the adaptive components pointed by the attributes and the other is used for changing the pointing method of the attributes;

step seven: repeating the fourth step to the sixth step to obtain a plurality of self-adaptive modules;

step eight: and the obtained self-adaptive module and the knowledge base are used for expanding the original software to complete the self-adaptive transformation of the software.

Preferably, the adaptation module in the step eight is obtained by integrating a plurality of adaptation modules.

Compared with the prior art, the invention has the following remarkable advantages

(1) The original code of the software system is changed less, and the structure is well preserved.

(2) In the using process, developers only need to concentrate on modifying the main business logic part, and the workload of the developers is reduced.

(3) And the system is independent of a third-party middleware system, so that the use is more flexible.

The specific implementation method adopted by the invention is as follows:

(1) and constructing a knowledge base and providing a storage structure of a plurality of groups of strategies.

(2) And combing the service logic of the original software system and organizing corresponding strategies according to the needs.

(3) And (4) giving the strategy details, normalizing the strategy details and storing the strategy details in an xml file form.

(4) And separating and extracting the service logic of the original software system as required, and packaging the service logic into a target object.

(5) And standardizing the target object, including unifying interfaces, adding business logic and other operations to form a self-adaptive component.

(6) Designing a connector, and initializing the attribute pointing of the connector to form a self-adaptive module.

(7) And (5) repeating the steps (4) to (6) to complete the design of a plurality of self-adaptive modules, and integrating the corresponding self-adaptive modules according to the requirements.

(8) And (5) the obtained self-adaptive module and the knowledge base are subjected to software self-adaptive transformation by using original extension software.

Has the advantages that: the self-adaptive software obtained by the transformation of the invention can respond to the self attribute and the complex environment change, and the transformation is based on the object-oriented design concept, thereby bringing great convenience for software maintenance.

Drawings

FIG. 1 is a diagram of the knowledge base UML class of the present invention;

FIG. 2 is an xml store description language for the context constraints of the inventive strategy;

FIG. 3 is an exemplary diagram of an adaptation module of the present invention;

FIG. 4 is an exemplary diagram of multiple linker associations of the present invention;

FIG. 5 is an exemplary diagram of a modified software system of the present invention.

Detailed Description

The following describes the specific implementation of the present invention in further detail with reference to the accompanying drawings:

A knowledge base used for storing strategies is constructed for original software, and a plurality of classes are required to be constructed in the process: a ContextEvent class to store context events, a ContextState class to store context state, a ContextRestriction class to store context constraints, a Restriction class to store constraint elements or logical relationships, a Condition class to store conditions, an Action class to store adaptive behavior, a Strategy class to store policies, a KnowledBase class to store sets of policies and provide methods to perform "monitor" steps, "analyze" steps, "plan" steps, "execute" steps, and so forth.

The context event stored by the ContextEvent class is a quad ContextEvent: { Sup: }_e,Attr_e,Rel_e,Val_eTherein Sup_eRepresenting a context provider, Attr_eIs represented by Su_eContext provided, Rel_eRepresenting a relational operator, Val_eRepresenting a critical value.

The context state stored by the ContextState class is a quadruplet, ContextState: bettue { Su_s,State,Rel_s,Val_sTherein Sup_sRepresenting the provider of the context State, State representing Sup_sState of the context provided, Rel_sRepresenting a relational operator, Val_sRepresenting a critical value.

The context constraint stored by the ContextRestriction class is the sequential storage of suffix expressions by multiple Restriction class instances. Thereby expressing a context constraint consisting of a plurality of constraints.

The instance stored by the recovery class may be either a constraint element or a logical relationship, and may be represented as a seven-tuple recovery: { Type, Rev, Relr, Sup: { (Type, Rev, Relr, Sup) }_r,Attr_r,Rela,Val_rAnd the Type distinguishes whether the current instance represents the constraint element or the logical relationship according to different values. Rev and Relr are used together to represent three operation relations of 'AND', 'OR' and 'NOT', Rev value determines 'NOT' relation, and 'AND' relation and 'OR' relation are determined by Relr value. Su (super food)_rThe provider of the context representing the Restriction, Attr_rRepresenting the context provided, Rela represents the relational operator, Val_rRepresenting a critical value. When the Restriction class instance represents a constraint element, the dependent attributes are Type, Rev, Sup_r,Attr_r,Rela,Val_r. When the Restriction class instance represents a logical relationship, the dependent attribute has a Type, Relr. Multiple retrieval instances in suffix formDuring storage, a stack structure is used for analysis, a complete context constraint relational expression can be obtained, and the influence of brackets in the constraint relational expression is avoided in such a way, so that a nested structure for storing the xml file by a strategy is eliminated.

The Condition Con stored by the Condition class may be represented as a triplet Con: { ContextEvent, ContextState, contextstatement }. Wherein ContextEvent corresponds to a context event, ContextSate corresponds to a context state, and ContextRestration corresponds to a context constraint.

The adaptive behavior stored by the Action class is a triple Act: { obj, op, Active }, where obj represents an executor of the adaptive behavior, op represents an operation to be executed by an execution component obj, and Active represents whether the current adaptive behavior is in operation.

The policy stored by the Strategy class is a four-tuple Strategy ═ { Con, Act, id, pr }, where Con denotes the condition, Act denotes the adaptation behavior, id is the policy identification, the policy id values corresponding to the same context event are the same, and pr denotes the policy execution priority.

The knowledgbaseclass provides a structure for storing the policies in groups according to the tag value id and the priority pr. The storage mode enables the inquiry of the strategies to be faster, and when a certain context event is triggered, the retrieval of the corresponding strategies can be completed only by inquiring a group of strategies with the same identification id and comparing the strategies according to the priority order.

The knowledge base constructed by the invention provides context events for the monitoring step of the self-adaptive software, is stored in a ContextEvent class and designates the monitored context Attr_eAnd context provider Sup_eAnd indicates when the context is within a threshold value Val_eExistence of the relationship Rel_eAnd (4) considering the event trigger of the context.

The knowledge base structure constructed by the invention provides context state for the analysis step of the self-adaptive software, stores the context state in a ContextState class, and specifies that the provider Sup analyzes the analysis after the context event is triggered_sContext State State is provided and indicates when the context State is in relation to threshold value Val_sExistence of the relationship Rel_sIt is considered that the "planning" step and the "execution" step need to be performed.

The knowledge base structure constructed by the invention provides context constraint for the planning step of the self-adaptive software. And when the self-adaptive adjustment is determined to be needed after the step of analyzing, analyzing a plurality of recovery class instance objects which are stored in the ContextRescription class instance and sequentially combined by the suffix expressions to obtain a context constraint relational expression. Comparing whether each constraint element in the constraint relation is satisfied, namely by the provider Sup_rProvided context Attr_rWhether or not to sum with a critical value Val_rThere is a Rela relationship between them and the corresponding logical relationship Relr is satisfied. And if both are satisfied, considering that the adaptive behavior specified by the current strategy can be performed.

The knowledge base structure constructed by the invention provides the self-adaptive behavior for the step of executing the self-adaptive software, the self-adaptive behavior is stored in the Action class, when the current policy context constraint is satisfied, whether the current self-adaptive behavior is in an Active state or not is judged, namely whether Active is true or not, and if true, the current self-adaptive behavior is in an activated state, the self-adaptive behavior does not need to be activated again. If false, the operation op is implemented by the adaptive behavior agent component obj, and the Active of the adaptive behavior is set to true.

FIG. 1 shows a UML example diagram of a knowledge base storage structure constructed by the present invention: there are a total of eight classes in fig. 1: a ContextEvent class, a ContextState class, a ContextRestriction class, a Condition class, an Action class, a Strategy class, and a KnowledBase class. Wherein the ContextEvent class represents a context event and the attribute suplier corresponds to a Sup in the context event quadruplet_eAttribute corresponds to Attr in context event quad_eAttribute relationType corresponds to Rel in context event quadruplet_eAttribute value corresponds to Val in context quadruplets_e. The ContextState class represents the context state, and the attribute suplier corresponds to the Sup in the context state quadruplet_sThe attribute State corresponds to the State in the context State quadruplet, and the attribute relationType corresponds to the context State quadrupletRel in the group_sAttribute value corresponds to Val in context-state quadruplets_s. The ContextRescription class represents a context constraint, the attribute primres is an array, and the storage element is a Restriction class instance. The attribute class represents a constraint element or a logical relation in the context constraint, the attribute Type corresponds to Type in the context constraint seven-tuple, the attribute reverse corresponds to Rev in the context constraint seven-tuple, the attribute relationship ForRestriction corresponds to Relr in the context constraint seven-tuple, and the attribute suplier corresponds to Sup in the context constraint seven-tuple_rAttribute corresponds to Attr in context-constrained seven-tuple_rThe attribute relation corresponds to the Rela in the context constraint seven-element group, and the attribute value corresponds to the Val in the context constraint seven-element group_r. The Condition class refers to a Condition in the ECA rule, is formed by combining a ContextEvent, a ContextState and a ContextState, corresponds to Con of a policy quadruplet, and is a one-dimensional array of attribute events, wherein a storage element is a ContextEvent class instance. The attribute state is a one-dimensional array, the storage element is a ContextState class instance, and the attribute recovery is an instance object of ContextState, representing the context constraint. The Action class refers to adaptive behavior and corresponds to Act in the strategy quadruple, the attribute object corresponds to obj of the Action triple, the attribute operation corresponds to op of the Action triple, and the attribute Active corresponds to Active of the Action triple. The Strategy class represents a policy, the attribute condition corresponds to Con in the policy quadruplet, the attribute action corresponds to Act in the policy quadruplet, the attribute id corresponds to id in the policy quadruplet, and the attribute priority corresponds to pr in the policy quadruplet. The knowledgbaseclass is used to store all the instances of the Strategy class, which are stored in the strategylarray according to the attribute id and the attribute priority, and provides a processing method. The method monitor is used for monitoring the context event and represents different monitoring results according to different return values. The method analysis is used for comparing context states and representing different analysis results according to different return values. The method plannerand analyzer is used for comparing context constraints and invoking different self-adaptive behaviors according to different return values. run method is used for simultaneous monitor, analysis and planenrand analyzer, and the method is used for simultaneous monitor, analysis and planenrand analyzerAnd the strategy is searched to complete the function of the whole knowledge base.

Firstly, it is necessary to specify the function of the software to be modified that needs to be adaptively adjusted, and the adjustment algorithm that the original software can provide, that is, some service logics. In this step, these business logics need to be combed out, which is a prerequisite for implementing adaptive reconstruction. After the self-adaptive adjustment requirement and the service logic of the original software are clarified, corresponding strategies are organized according to the requirements, and four factors are considered for constructing the strategies: event Ce, state Cs, restraint Cr, and adjustment Ac. The event Ce represents an event that may occur during the running process of the software and affects the normal running of the software, and is represented by that some attribute of the software system itself or the current environment exceeds a critical value, and the attribute should be perceivable by the software. The state Cs represents the different states that the software is in when running, and some property of the software system itself may represent this state. The adjustment Ac represents an adjustment behavior that the software system can perform when coping with the event Ce, and the behavior can enable the software system to operate normally again, and the behavior is often various. The constraint Cr indicates the software itself or the environmental attribute that needs to be concerned when making the adjustment Ac, and there is often an optimal adjustment Ac that can be performed under different constraints Cr. By comprehensively considering the four factors, a plurality of groups of strategies described according to the ECA rule 'if condition the action' form can be summarized.

And giving the details of the strategy, normalizing, and refining and normalizing the strategy according to eight types of attributes stored in a knowledge base in a mode that an event Ce corresponds to a context event ContextEvent, a state Cs corresponds to a context state ContextState, an Ac corresponds to an adaptive behavior Action, and a constraint Cr corresponds to a context constraint ContextState. And store these policies in an xml file. xml refers to extensible markup language, which is easy to store and read, and is well-established in the industry and will not be described in detail herein.

The elements and the logic relation in the context constraint expression are stored in a suffix expression form, and the form avoids a nested structure in the xml file and enables the xml file to be conditioned more clearly.

FIG. 2 is a diagram of the context constraint expression A & & (B | | C) & & &! Xml description language for D:

context constraint A & & (B | | C) & &! There are a total of four constraint elements A, B, C, D and three logical relationships "and" or "and" not "in D. Firstly, extracting the 'not' relation in the constraint element, and recording the Rev value in the D as true. The whole is then expressed as a suffix expression, i.e. ABC or and D and:

lines 1 to 5 in FIG. 2 represent constraint element A, where Supplier ═ ClassA corresponds to Sup in the heptad_rIndicating that the provider of the element is ClassA; attribute ═ A "corresponds to Attr in the seven-tuple_rIndicating that the context provided by ClassA is "a"; type is 0, which corresponds to Type in the seven-element group, and indicates that the current restiction represents a constraint element; the Reverse ═ False corresponds to Rev in the seven-element group, which means that there is no "not" relationship for the current constraint element; lines 2 to 4 are used to represent the context of the constraint element a and the threshold Value comparison, so as to distinguish whether the constraint is satisfied, the relationship of "is" for the relationship of "is" in the seven-element group, the relationship operator is ", and the Value of" true > true "for the line 3 corresponds to Val in the seven-element group_rThe critical value is true. The entire constraint element A indicates that the constraint is satisfied when the context "A" value provided by ClassA is true. Lines 6 through 10 represent the constraint element B, supra. Lines 11 through 15 represent constraint element C, supra. Lines 16 to 17 indicate that there is an or relationship between the constraint element B and the constraint element C, and the Type of line 16, 1, corresponds to the Type of the seven-tuple, indicating that the current restiction represents a relationship between one constraint element. Relationship for recovery "or" corresponds to Relr in the seven-element group, indicating that an "or" relationship exists between constraint element B and constraint element C. Similar to lines 16 through 17, lines 18 through 19 represent constraint elementsAn and relationship exists between element a and B C. Lines 20 through 24 represent the constraint element D, and there are different points with the constraint element A, B, C, where Reverse ═ true in line 20 corresponds to Rev in the seven-element group, indicating that there is a "not" relationship for the current constraint element D, i.e., the constraint is satisfied when the value of D is not true. Similar to lines 18 through 19, lines 25 through 26 represent constraint elements A&&An AND relationship exists between (B | | C) and the constraint element D

In this step, the business logic that can be used to accomplish the adaptive behavior in the original software system is extracted from the source code and encapsulated into the target object. In the step, the code to be processed is abstracted into a section, each execution step of the code is abstracted into points of interest, main business logic in the points of interest is abstracted into connection points, and the connection points put forward the business logic in a proxy mode in an object-oriented programming design mode and package the business logic to form a target object. The specific method comprises the following steps:

firstly, determining a connection point, wherein service logic in an original software system code is often surrounded by various business logic codes such as a write log, a read log and the like layer by layer, and the step needs to determine the service logic, namely the connection point.

And secondly, separating the concerned points, sorting codes, separating the business logic from other business logic, and determining the execution condition of other business logic around the connection point.

And thirdly, repackaging the business logic, namely, packaging the business logic into a proxy class to form a target object by using a proxy mode in an object-oriented programming design mode.

The target object obtained in the step can dynamically proxy the execution of the original algorithm when the software runs, and the original service logic is realized. The obtained target object is modified, so that the original service logic can be dynamically modified, and the source code cannot be damaged.

And standardizing the target object, wherein the operation comprises the steps of unifying interfaces, adding transaction logic and the like to form an adaptive component. When the self-adaptive software deals with the same context event, different self-adaptive behaviors are triggered according to different states or attributes of the self-adaptive software, the self-adaptive behaviors correspond to different target objects extracted in the previous step, a strategy mode in an object-oriented programming design mode is used in the step to unify interfaces for the different target objects, and business logic around a connection point in the original software is added according to needs, or new business logic and the like are added to complete standardization of the target objects. The standardized target object has the function of completing corresponding adjustment behaviors, and the target object obtained in the step is used as an adaptive component.

In the step, a connector is designed by using the object-oriented programming characteristic, the connector has two attributes and two methods, the two attributes point to two adaptive components connected by the connector, the first method of the connector gives the operation logic of the adaptive components designated by the two attributes, and the second method of the connector can analyze the incoming parameters and change the self attribute point. The adaptive component and the adaptive connector in the invention have the same interface, so that the two attributes of the connector point to either the adaptive component or the connector.

FIG. 3 is a diagram illustrating an example of an adaptive module:

the self-adaptive module consists of an interface Block and five classes: GCS _ Failsafe _ Connecter class, PreAction class, Continue _ Session class, Loiter class, RTL class, etc. The five classes are implementation classes of the interface Block, run methods and change methods of the interface Block are implemented, and different methods are packaged in the respective run methods. GCS _ Failsafe _ Connector is a connector of an adaptive module and is provided with two attributes b1 and b2, and two methods run method and change method, wherein the attribute b1 initially points to the PreAction class of the interface Block, the attribute b2 initially points to the Continue _ Mission class of the interface Block, the run method gives the running logic of the adaptive component pointed by the two attributes, the run method of the GCS _ Failsafe _ Connector class is operated to adjust the pointing of the attributes b1 and b2 of the connector GCS _ Failsafe _ Connector class according to the run method of the adaptive component pointed by the logic running attributes b1 and b2, and the change method adjusts the pointing of the attributes b1 and b2 of the connector GCS _ Failsafe _ Connector class according to different input parameters. The PreAction class, which is a reserved class of the adaptive module, is replaced when multiple adaptive modules are connected, or is replaced according to the logic of the source code. The Continue _ Session class, the Loiter class and the RTL class are self-adaptive components, which respectively proxy the related service logic of the original software and have different degrees of extension in the run method of the self. In this adaptation module, when the adaptation component pointed to by the attribute GCS _ failure _ connector class b2 changes, the adaptation behavior of the system changes.

In the step, the steps (4) to (6) are repeated to complete the design of a plurality of adaptive modules, and the plurality of adaptive modules can be integrated according to the requirement. The connection of each self-adaptive module is more compact. The method comprises the following specific steps: and a connector is newly built, and each connector can only be connected with two self-adaptive components or connectors, so that n +1 connectors are needed for integrating n self-adaptive modules. By pointing one attribute of each adaptation module's connector to the adaptation component and another attribute to the next connector, different adaptation modules can be integrated. The connectors of the integrated adaptive module form a binary tree structure, the adaptive member is equivalent to a leaf node of the binary tree, and the method of the adaptive member and the next connector is operated according to the operation logic in each connector method. The integrated adaptation module can thus run all the adaptation component methods in sequence by running only the root node's connection sub-method. If a large amount of business logic needs to be processed between different self-adaptive component operations, integration can be omitted, and the self-adaptive module is operated independently, so that the flexibility in expansion is ensured.

Fig. 4 is a diagram showing a structure example of multiple linker associations:

fig. 4 consists of an interface Block and five classes: the Adaptive module comprises a PreAction class, a Start _ Connector class, a BatteryEvent _ Adaptive class, a NoGCS _ Adaptive class, an EndAtion class and the like, wherein the PreAction class and the EndAtion are reserved classes, and the Adaptive module is considered and perfected according to original logic of non-Adaptive software when being used as an extension and woven into source code. The Start _ connector class is a connector added during the integration of the Adaptive module, n +1 connectors are needed during the integration of n Adaptive behaviors, the Start _ connector class is an expanded connector, the attribute b1 points to the PreAction class, and the attribute b2 points to the BatteryEvent _ Adaptive class. BatteryEvent _ Adaptation is that the link sub-attribute b1 of the first adaptation module points to the adaptation component that is to accomplish the adaptation behavior, not shown, and the attribute b2 points to the link sub-NoGCS _ Adaptation class of the next adaptation module. The NoGCS _ Adaptive class is the adaptation linker of the second module, the attribute b1 points to the adaptation component that accomplishes this adaptation behavior, not shown, and the attribute b2 points to the EndAction class. The whole system can sequentially run methods of a PreAction type, a BatteryEvent _ Adaptive type, a NoGCS _ Adaptive type and an EndAtion type by running the run method of the Start _ Connector.

The step is to take the knowledge base and the self-adapting module which are constructed before as the extension to be woven into the source code of the original software. It should be noted that, in the present invention, the function of the knowledge base is to adjust the adaptive component pointed by the attribute of the linker, so as to change the behavior of the system, and therefore, the operation of the knowledge base should be before the operation of the adaptive module. On the premise, the relation between the self-adaptive service logic and the service logic which does not need self-adaptation is adjusted, and the normal operation of each service logic after the non-self-adaptive software is subjected to self-adaptation transformation is ensured. FIG. 5 is an exemplary diagram of non-adaptive software modified by the present invention: fig. 5 can be divided into 3 partial knowledge base parts, a non-adaptive software part and an adaptive module part. In the figure, the UAV class refers to original software. The knowledge base part is similar to that in FIG. 1, and comprises a ContextEvent class, a ContextState class, a ContextRestriction class, a Condition class, an Action class, a Strategy class, and a KnowledBase class. The rest is an adaptive module structure, like fig. 4. The unified interface Block is integrated into the software UAV in a combined relation and participates in the running process of the software UAV, and meanwhile, the software UAV depends on a knowledge base class. When the modified software UAV runs, a run method in a knowledgbasee class is called first, the whole self-adaptive loop of monitoring, analyzing, planning and executing is completed, a system structure which is subjected to self-adaptive adjustment is obtained, and then a self-adaptive module is operated.

Claims

1. A software self-adaptive transformation method based on object-oriented programming is characterized by comprising the following steps:

the method comprises the steps of combing original service logic of software to be modified, defining self-adaptive software requirements, abstractly expressing the requirements into an event Ce, a state Cs, constraint Cr, adjustment Ac, and a strategy described according to an ECA rule 'if condition the action' form;

according to the fact that an event Ce corresponds to a context event, a state Cs corresponds to a context state, the adaptive behavior corresponding to Ac is adjusted, the mode that a constraint Cr corresponds to the context constraint stores the provided attributes according to a knowledge base, strategies are refined and normalized, and the strategies are stored in an xml file;

step four: separating and extracting the service logic of the original software system as required, and packaging the service logic into a target object; repackaging the service logic of the original software system by using a proxy mode in object-oriented programming to obtain a target object;

the connector has two attributes pointing to the adaptive components and two methods, wherein one method is used for coordinating the operation method of the adaptive components pointed to by the attributes, and the other method is used for changing the pointing method of the attributes;

2. The software adaptive modification method based on object-oriented programming according to claim 1, characterized in that: the adaptive module in the step eight is obtained by integrating a plurality of adaptive modules.