An application of artificial intelligence to object ...

849

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 20, NO. 11, NOVEMBER 1994

An Application of Artificial Intelligence to ObjectOriented Performance Design for Real-Time Systems Shinichi Honiden, Member, IEEE, Kazuhiko Nishimura, Naoshi Uchihira, Member, IEEE, and Kiyoshi Itoh, Member, IEEE

Abstract-Thii paper describes an application of artificial intelligence technology to the implementation of a rapid prototyping method in Object-Oriented Performance Design (OOPD) for real-time systems. OOPD consists of two prototyping phases for real-time systems. And each of these phases consists of three steps: prototype construction, prototype execution, and prototype evaluation. We present the following artificial intelligence based methods and tools to be applied to the individual steps. In the prototype construction step, a rapid construction mechanism using reusable software components is implemented based on planning. In the prototype execution step, a hybrid inference mechanism is used to execute the constructed prototype described in declarative knowledge representation. MENDEL, which is a Prolog based concurrent object-oriented language, can be used as a prototype construction tool and a prototype execution tool. In the prototype evaluation step, an expert system which is based on qualitative reasoning is implemented to detect and diagnose bottlenecks and generate an improvement plan for them.

(Performance model constructin)

I

Prototype evaluation step (Performance diagnosis and Improvement plan generation)

1 Prototype execution step (Performance measurement)

Fig. 1. Prototyping process in performance design.

satisfy the performance requirements under a given hardware configuration. In other words, OOPD activities are usually carried out on a trial-and-emr basis. These activities can be regarded as a prototyping approach to handle ill-defined problems. Index Terms- Artificial intellience, object-oriented design, Although only a few algorithms are available for illdefined performance design, planning, qualitative reasoning, real-time problems, the artificial intelligence technology has been efsystems, software prototyping. fectively used to tackle such problems. Various illdefined problems are actually Seen in the software engineering field. Several attempts have been made to apply artificial intelliI. INTRODUCTION BJECT-ORIENTED TECHNOLOGY can provide de- gence techniques to these ill-defined problems in the softsigners with practical, productive ways to develop software engineering field. W i c a l examples are GIST [51, [MI, ware in most application areas. For real-time applications, Programmer’s Apprentice [41], 40 [2], Glitter [lo], Dataobject-oriented technology has been practically employed in Representation Advisor [26], ASAP [l], SC [9], and AFFIRM a number of systems. Recently, various multi-processors have [131. These methods seem to be successfully applied to particbecome commercially available and have been used in many ular phases or domains. The individual methods can be used applications. Since stringent performance requirements are to handle several steps in the software development process, inevitable for real-time applications, it is very important to but none of them can cover the overall development process predict the target system performance precisely during the nor can be used to fully implement the prototyping process. A prototyping process is defined to be composed of three design phase to determine the optimal software and hardware configurations which will satisfy the users’ requirements. steps: prototype construction, prototype execution, and protoHowever, in some real-time systems on multi-processors, it type evaluation, as shown in Fig. 1 [19]. is quite difficult to adjust some of the performance factors, such as load-balance on a given multi-processor architecture, A. A Prototyping Process to satisfy the performance requirements. In practice, the perforThe following describes the fundamental requirements for mance design activities in the object-oriented design-called implementing the three steps in the performance design for Object-Oriented Performance Design (OOPD~processtend real-time systems. to be empirical, because there are few algorithms which 1) Prototype Construction Step: It is essential.for any procan derive the optimal software configurations which will totyping method to be able to handle large-scale programs.

0

Manuscript received September 23,1992; revised September 1993. Recommended for acceptance by A. C. Shaw. S. Honiden, K. Nishimura, and N.Uchihira are with Systems and Software Engineering Laboratory, Toshiba Corporation, Kawasaki 210, Japan K. Itoh is with Faculty of Science and Technology, Sophia University, Tokyo 102, Japan. IEEE Log Number 9406406.

High software productivity during prototyping is also required in order to construct prototypes rapidly. Software reuse methods have been considered as one of the most effective methods for increasing software productivity, and are employed in several domains [25]. Various specification methods, such as keyword, case grammar, and formula, have been proposed to

0098-5589/94$04.00 0 1994 IEEE

Authorized licensed use limited to: Universidad Tecnica Federico Santa Maria. Downloaded on July 6, 2009 at 11:29 from IEEE Xplore. Restrictions apply.

850

IEEE TRANSACTIONS ON SOITWARE ENGI"G,

retrieve reusable components. The larger the system, the more components it will have. To satisfy the rapidity requirement in the prototype construction step, the cost necessary to retrieve the reusable components must be minimized. 2) Prototype Execution Srep: One of the major properties essential to prototyping is executability, meaning that the following requirements should be satisfied. Rapid execution. Execution without complex preparation. Visual execution while displaying results which are easy to evaluate. Arbitrary interruption and re-starting during execution. From the standpoint of performance design, it is necessary to produce visual performance data during execution and to collect and evaluate it effectively since performance simulation usually takes a long time. For example, during execution, it is important to display the queue lengths, as well as dead-lock detection in real-time. The collection of performance statistics factors including the queue length, the utilization rate, and the wait time at each server, as well as the response time is also required. 3) Prototype Evaluation Srep: An inadequate evaluation may slow down the whole prototyping process. This factor violates one of the main prototyping properties of rapidity. The following requirements should be satisfied to solve this problem in the prototype evaluation step. a) Rapid detection of any bugs which would produce undesired output. b) Rapid generation of appropriate improvements. c) Supporting designerher interaction during prototype evaluation. d) Inexpensive observation of the intended system while frequently changing the system constraints [33]. From the viewpoint of performance design, the functions that achieve the above requirements a) and b) are indispensable for the rapid detection of bottleneck sources and the rapid generation of appropriate performance improvement plans. At present, the prototype evaluation step is time-consuming and difficult for a designer who has limited experience and is not familiar with performance design, because there are few standard methods which can support to satisfy these requirements. It is necessary to automate this step so that such designers can accomplish the design tasks accurately, rapidly, and appropriately. As mentioned previously, using a performance simulator generally takes much time to accomplish the prototype execution step. Reducing the prototyping cost also depends on the rapid generation of appropriate improvement plans. It is important in real-time systems on multi-processors to validate the performance of the constructed prototype, which is mapped to given multi-processors. The constructed prototype must be evaluated on the given multi-processors in the prototype evaluation step. We present the following artificial intelligence based methods and tools to be used in these three steps. In the prototype construction step, a rapid construction mechanism using reusable software components is implemented based on planning 1341.

VOL. U). NO. 11, NOVEMBER 1994

In the prototype execution step, a hybrid inference mechanism is used to execute the prototype described in declarative knowledge representation. We have implemented MENDEL as the executable specification language. MENDEL is a Prolog based concurrent objectoriented language [151, [17], [MI, [&], which can be used as a prototype construction tool and a prototype execution tool. In the prototype evaluation step, an expert system based on qualitative reasoning [8] is implemented to detect and diagnose bottlenecks and generate appropriate improvement plans. We have developed two knowledge-based expert systems on the basis of heuristics and knowledge obtained from experts, BDES (Bottleneck Diagnosis Expert System) and BIES (Bottleneck Improvement Expert System) 1211, [22], 1241. BDES qualitatively diagnoses or identifies bottlenecks and their sources, and generates a qualitative improvement plan. BIES quantitatively estimates the effects of the improvement for bottlenecks and their sources on the whole queuing network. We have also developed BDES-S (BDES for open Synchronized queuing network) and BIES-S (BIES for open Synchronized queuing network) [23].

B. OOPD It is important in designing real-time systems to consider both functional and performance aspects. Two prototypes exist in designing real-time systems: functional and performance prototypes. Functional design should be accomplished while satisfying the performance requirements. The performance requirements must be satisfied under several constraints during function implementation. Examples of constraints are the number of processors and the configuration of an application software. These constraints may affect the actual performance and are determined in accordance with the functional design actually developed. Therefore, prototyping should be done under the defined constraints at various design phases. We present OOPD, which consists of two prototyping phases for real-time systems. The prototyping process of OOPD is shown in Fig. 2. Some of these phases can be omitted if necessary. For example, Phase2 can be omitted if the synchronization problem does not occur in some applications. Each of the two phases has prototyping processes as follows. 1) Phase1 : a) Prototype consrrucrion and execution sreps: OOPD starts by logical architecture construction. OOPD assumes that all necessary OBJECT'S for object design have already been stored in the object library at the object-oriented analysis (e.g., [4]) stage. Each OBJECT in the logical architecture is specified by MENDEL. In addition, each OBJECT includes several METHOD'S.In the prototype construction step, the logical architecture, which consists of several OBJECT'S that satisfy the functional requirement, is designed and mapped into the physical architecture of the given multi-processors. The logical architecture is constructed rapidly using planning. Each OBJECT has information about the processing volume and the branching probability obtained by pre-simulation or estimation


HONIDEN et d.:APPLICATION OF ARTIFICIAL INTELLIGENCE To OBJECT-ORIENTED PEFWORMANCE DESIGN

Section V compares the presented method with related work and Section VI provides some brief-conclusions.

Object-Oriented Analysis

I

I

1

(,se;

-

II.

Prototype mnsmction and execution steps

and executionsteps

Performance evaluation Prototype evaluation

I

SUPPORT TOOLS FOR PROTOTYPE

CONSTRUCTION AND EXECUTIONSTEPS

I

Define input and output of OBJECTS

85 1

Refinement

“P

In real-time systems, the combination of declarative knowledge description and actor-based object modeling is considered to be one of the effective methods of developing a prototype. The interrelationships among the objects are described with actor-based object modeling, and the intemal behaviors of individual objects are described using declarative knowledge. MENDEL is implemented as the executable specification language which provides the above functions. MENDEL is a Prolog based concurrent object-oriented language [151, [171, [18], [&I, which can bi: used as a prototype construction tool and a prototype execution tool. A. MENDEL OBJECT: A Concurrent Reusable Component

1

Object-Oriented Programming

Fig. 2. OOPD overview.

as a unit server. This information is used to perform simulation under the condition that composed OBJECT’s are mapped to a queuing network. After the simulation, the resulting data will be used in the prototype evaluation step. b) Prototype evaluation step: The prototype evaluation step enables the reestimation of the logical architecture from the viewpoint of message quantity and processing time for OBJECT’S. In OOPD, the initial logical architecture which consists of appropriate OBJECT’s is very important to minimize corrections in the subsequent design steps. The estimation of the OBJECTS’ structures in terms of their performance has much significance. BDES and BIES can be used to examine and improve the initial logical architecture. 2 ) Phase2: a ) Prototype construction and execution steps: In Phase2, the METHOD’s obtained in Phase1 are refined by speclfying synchronization among the METHOD’s. The synchronization problem occurs when multiple METHOD’s access intemal data in an OBJECT. With regard to the processing of the METHOD’s, the problem of synchronizing several messages arriving at the METHOD must be managed. If a METHOD needs several messages, it must wait until all the messages arrive. Generally, synchronization that affects the performance of concurrent programs must be examined. b) Prototype evaluation step: BDES-S and BIES-S can be used to examine performance degradation caused by synchronization. Also, message distribution among OBJECT’s and METHOD assignment in OBJECT’s are examined and improved. The rest of the paper is organized as follows. Section 11 describes the support tools for the prototype construction and execution steps and Section III describes the prototype evaluation step. Section IV describes how to use support tools.

Each OBJECT has pipe caps and can transmit messages only through the pipe caps, as shown in Fig. 3. An attribute is assigned to each pipe cap and is used to identify inputloutput messages. Messages are transmitted between OBJECT’Sthrough the transmission pipe attached to the pipe caps. Each OBJECT consists of a block of working-memory and several METHOD’s, as shown in Fig. 4. Each message consists of an attribute name, an inputloutput identifier-“?” or “!”, and a variable name. If a message preceded by ‘?“ is received as a METHOD’s variable, the METHOD’s Prolog clauses are invoked. When the METHOD is executed, the variable preceded by “!” will be unified and sent to the other OBJECT’s as a message. Each METHOD is regarded as a productionrule and is used in the forward inference mechanism. A METHOD consists of a left-hand side (LHS) and a right-hand side (RHS). An LHS contains input messages and an RHS contains output messages. Both LHS and RHS contain intemal state variables, which are stored in the working-memory. METHOD selection in a conflict set is nondeterministic. The body part of a METHOD consists of Prolog clauses. MENDEL also supports several simulation predicates for statistical performance simulation. Each METHOD includes a backward inference engine, since the Prolog system can be regarded as a backward inference engine. The overall architecture is a distributed production system, in which each OBJECT has an inherent working-memory and both forward and backward inference mechanisms. In MENDEL, a simple synchronization mechanism is achieved by using a METHOD selection mechanism, similar to Dijkstra’s guarded command [7]. The OBJECT is suspended until it receives all the required messages. Fig. 5 shows the basic format for a MENDEL OBJECT. Figs. 6 and 10 show the description examples. MENDEL provides both functional visual execution and statistical performance simulation as a prototype execution tool. In functional visual execution, an activated OBJECT can be displayed as blinking on the screen, and message queues and the message contents are displayed in real-time. MENDEL also collects statistical performance data by simulating OBJECT’s as the servers in a queuing network.

I


IEEE TRANSACTIONS ON SOFTWARE E N G I “ G ,

852

Fig. 3. Interconnections among MENDEL OBJECT’S.

METHOD = Production Rule

VOL. 20, NO. 11. NOVEMBER 1994

MENDEL OBJECT::= Ospec # < object name >, precondition # [(< precondition list >)I, delete # [< delete list >)I, add # [(< add list >)I. OBJECT < object name >(< message list >) is [ < variable declaration > ] (< method declaration >)+ end [< object name >I; < precondition list >::= ()+ < delete list >::=(< input data >)+ < add list >::=(< output data >)+ < input data >::=(< attribute name >(< attribute value >)+)+ < output data >::=(()+)+ < message list >::= (< attribute name > < 1/0 ID. >:< variable name >)+ < 1/0 ID. >::=? ! < variable declaration >::= variable (< variable name >:[< type >I[=< initial value >I)+ end < method declaration >::= METHOD < method name >([< message list >]) - > < guard part > ‘‘I” < body part > < guard part >::= [< variable name > < binary operator > < value >]+ < body part >::= < sequence of PROLOG clauses > I < simulation predicate >::= $ seize(< resource name) I $ release(< resource name >) I $hold(< CPU time >) (Note: “J)( is the commitment operator of the concurrent logic programming language.)

Fig. 5. Basic format of MENDEL OBJECT.

Ospec # door-controller, precondition # [doorst at us(Lift, close), liftwaiting( Lift ,FloorNo), requests( Lift,FloorNo) 3, delete # [ doorstatus(Lift,clcse) 1, add # [ doorstatus(Lift,open) 1.

LHS

Fig. 6. Sample specification in OBJECT for planning.

Fig. 4. A MENDEL OBJECT.

prototype which generates output data from input data. Fig. 6 shows a sample specification of an OBJECT for planning. The specification of an OBJECT for planning consists of a precondition list which represents input data, an add list which represents output data, and a delete list which represents input data that is consumed within the OBJECT. For example, Fig. 6 shows a door-controller OBJECT which controls the opening and closing of a door of a lift (an elevator). When the OBJECT receives signals which indicate that the door is closed and the lift is at the desired floor, it generates a signal that instructs the door to open. At the same time, the signal which indicates that the door is closed is removed. The planner regards the specification for input data as the B. Planning initial condition and regards the specification for output data MENDEL adopts planning using reusable components (OB- as the goal. It generates a sequence of OBJECT’S which JECT’S)to contribute to rapid prototype construction. Planning satisfy the goal, the first OBJECT is applied to the initial generates a sequence of actions or an action program for an condition and the following ones are applied to the outputs agent, such as a robot [34]. Planning can be used to construct of the previous ones in turn. The problem is first solved in an a prototype. Planning generates a set of OBJECT’S which abstract space and the abstract solution is refined at successive satisfies the requirements specification given by the designer. levels in the hierarchy. The following description defines the The requirements specification represents the information per- method to automatically assign criticality values to determine taining to input and output data. An OBJECT is a unit in the abstraction hierarchy, and also defines the requirements

MENDEL OBJECT is mapped to an executable specification. The executable specification is created using Prolog system which has been extended to include the real-time OS commands such as activate (activation of task), term (termination of task), send (sending message to mailbox), check (checking message in mailbox), wait (receiving message from mailbox), getb (creation of mailbox), and freeb (distraction of mailbox). Then, we are able to simulate the application program on a pseudo real-time OS environment and to develop the actual code on object-oriented real-time OS’s such as CHAOSafC[141.


853

HONIDFiN et al.: APPUCATION OF ARTIFICIAL INTELLIGENCE TO OBECr-ORIENTED PERFORMANCE DESIGN

specification and OBJECT’s which are given to the planner. An example is used to demonstrate the mechanisms of the planner in detail. I) Assigning Criticality Value: A typical hierarchical planner, Abstrips [42], has been implemented as a problem solver more efficiently than a single level problem solver. Abstrips introduces the concept of a criticality value for the precondition list with regard to the knowledge (operator), e.g., representing the behavior of a robot. However, the designer is required to give the criticality value based on his experience (pre-defined). Thus, it is difficult to specify a proper criticality value which improves the performance of problem solving. This paper describes a method which can be used to automatically assign criticality values to the preconditions of the OBJECT’s using only the knowledge on the OBJECT’s. The generation of criticality values consists of the following three stem. First, a taxonomic hierarchy is created from a set of primitive OBJECT’s. OBJECT’s that share one or more output data contained in the add list reside in the same tree within a taxonomic hierarchy. Higher levels within a taxonomic hierarchy have more important input data which are used to generate specific output data. Provisional criticality values are assigned to the preconditions of primitive OBJECT’Sfrom the taxonomic tree. Input data appearing in the preconditions of abstract OBJECT’s which reside in a higher level within the taxonomic tree are assigned higher values. The same value is assumed for the same level. The difficulty of achieving each precondition is evaluated for each input data appearing in the preconditions. It is defined by the frequency of use of each input data in the precondition list of all primitive OBJECT’s. A higher frequency indicates that achieving that precondition is more difficult and that the situation should be solved urgently. The above evaluation is used to improve the provisional values assigned in b). More than one input data may be assigned the same value as the result of b). The provisional values are modified so that input data which are more important and difficult to achieve are moved to higher levels, according to the evaluation. Fig. 7 illustrates an example taxonomic hierarchy of the OBJECT’s in Fig. 3. The OBJECT’s m3 through m5 satisfy the conditions described in Section 11B1) a). Since OBJECT’s m3 and m4 have output data c in the add list, an abstract OBJECT AB01 is created with the common part of the precondition lists of m3 and m4 as its precondition list. In this case, a1 appears both in the precondition lists of m3 and m4, and b is the name of the concept which is the upper level of b2 and b3. Furthermore, since m5 also has c in its add list, an abstract OBJECT A B 0 2 is generated. As a result, an OBJECT taxonomy shown in Fig. 7 is generated. The provisional values for the preconditions are generated from the created taxonomic hierarchy. The preconditions of abstract OBJECT’s which are located in higher levels within the taxonomic hierarchy are analyzed, and input data which appear in a higher level are given a higher value. Input data that

a2 b2 a1 b2

@b1 a1 a2

Fig. 7. OBJECT taxonomy.

appear only in the preconditions of the primitive OBJECT’s are given the lowest value. Within the taxonomic hierarchy shown in Fig. 7, the abstract OBJECT A B 0 2 which is located at the highest level has the precondition al. The abstract OBJECT A B 0 1 which is located in the level just below the highest level has b in addition to al. Since b is the upper concept of b2 and b3, b2 and b3 are assigned to the level just below a l . The remaining a2 and d are assigned to the lowest level. That is, a1 is set to 3, b2 and b3 are set to 2, and a2 and d are set to 1. In the next step, the difficulty of achievement is evaluated for each precondition. Difficulty here indicates how many conditions should be checked to satisfy a specified condition. In other words, the more candidate OBJECT’s that are obtained by satisfying the specified condition, the more difficult the condition is considered to be. For example, assume that a primitive OBJECT has one C and two D conditions within its precondition. D needs to be collated twice, while C only once. Thus, the planner consumes twice the cost for satisfying D compared with satisfying C. If a costly condition such as D is given a low urgency, the number of combinations may increase and the efficiency of searching may become lower. Conditions such as D should be examined in a more abstract space. To do so, the provisional value generated earlier should be modified so that the conditions which are more difficult to satisfy are examined earlier. As a result, the preconditions that need to be examined in order to use the primitive OBJECT’s are sorted according to their importance and difficulty. For example, in Fig. 7, since b2 appears in m2 and m3, and b3 appears in m4, b2 is assigned to a level higher than b3. The resulting criticality values of a l , b2, and b3 are set to 4,3, and 2 respectively, and those of a2 and d are set to 1. 2) Initial Condition and Goal: The requirements specification that the designer should describe to perform the OBJECT’Scomposition will be discussed. The requirements specification describes the input data which the system receives from the outside, and the output data which the system generates to the outside. Each data item has an attribute name and an attribute value. 3) Search Control: The planner has the same behavior as that of Abstrips. A problem is solved by examining only the conditions to which the highest criticality value is assigned, and an abstract plan is generated. Then, the abstract plan is


854

.

IEEE TRANSACllONS ON SOFTWARE ENGINEERING, VOL. 20, NO. 11, NOVEMBER 1994

successively refined in a more detailed problem space which is defined by ignoring conditions with less than the next highest criticality value. In each problem space, OBJECT’s are selected based on the means-ends analysis [ l l ] as follows. a) Calculate the difference between the goal and the current state. If no difference is observed, the final solution is obtained. b) If any difference is observed, an appropriate OBJECT that can reduce the difference is selected. c) If the selected OBJECT can be directly applied to the current state, it is applied to the current state to generate a new state which is to be considered the new current state, then go back to a). If it cannot be applied directly, set the condition which prevents it from being applied as a sub-goal, go back to a), and repeat the procedure. As a result of the above procedure, the plan obtained in the lowest abstraction level represents the desired sequence of OBJECT’s. If the obtained sequence of OBJECT’s does not satisfy the user’s intention, an altemative is generated by normal chronological backtracking.

TABLE I

ABSTRACr HIERARCHY

Requests

Explanation

Request to be stopped

Our

Informationfor building structure Current security information for buildin

Buildingstatus

Liftwaiting

I

Sacerdoti’s method method

1 7 3

Acknowledge signal for requests

C. Experimental Results

We used the hierarchical planner Abstrips implemented with Quintus-Prolog on SUN-4/260 for an experiment. The abstract hierarchy which has been developed based on the heuristic criteria experientially defined by Sacerdoti [42] was used to prove the effectiveness of our method for prototype construction. The experimental results were evaluated by analyzing the CPU time, the number of nodes expanded at each abstraction level, and the number of elements within the OBJECT set finally obtained. We used the planner to solve seven different problems (requirements specifications)each having a different number of OBJECT’s. The input data in the precondition of each OBJECT are shown in Table I. The third and fourth columns show the criticality values obtained by our method and by Sacerdoti’s method [42]. Fig. 8 shows a graph which represents the relationship between the number of elements within the OBJECT set (horizontal axis) and the corresponding CPU time (vertical axis). Fig. 8 illustrates two experimental results, one which uses the abstract hierarchy obtained by Sacerdoti’s method [42] and another which uses the abstract hierarchy obtained by the method described in this paper. Our method takes less CPU time than the Sacerdoti’s method. In particular, the difference between the two CPU times becomes larger when the number of elements in the OBJECT set increases. This difference is the result of the effectiveness of the plans that are generated in a higher space; if an abstract plan works as a good guidance for the successive problem solving, the planner takes less CPU time. Table 11 summarizes the number of nodes evaluated at each level, the length of the plan (the number of OBJECT’s), and the CPU time for Problems 1 through 7. The reader can recognize at a glance that most of the problems are solved in a higher space such as level one or two

I

Input data

6

1

5

1

4

2

3

2

2

4

I 2 1

Current floor no. of lift

[sec] 11

10-

9-

i

8-

! 8

4

4

8

12

16

20

24

Number of OBJECTS A Our method 4-Sacerdoti’s method

Fig. 8. Comparison of the number of OBJECT’s and CPU time.

when our method is used, whereas many nodes are evaluated in a lower space such as level three or four when the Sacerdoti’s method is used. Our method has been evaluated on more than 50 randomly generated problems. The results indicate that our method produces the solutions in less time than Abstrips. As described above, the proposed method, hierarchical problem-solving using an abstract hierarchy, employs a hierarchy of abstract problem space to first solve a problem in an abstract space and then refines this abstract solution into successively more detailed spaces. The automated approach to generating the abstraction hierarchy has also been described. This approach forms abstractions by examining the OBJECT’s that share common outputs, and then comparing the frequency of input data in the precondition. Compared to Sacerdoti’s method, the proposed method produces more effective abstractions with less knowledge. In the prototype construction step, the planner needs to assure the functionality of its output. To satisfy this requirement,


855

HONIDEN er 01.: APPLICATION OF ARTIFICIAL INTELLIGENCE To OBJUJT-ORLENTED PERFORMANCE DESIGN

TABLE II NUMBEROF NODESEVALUATED BY PLANNER AT EACHLEVEL

-

emeraencv,

-6utto;l

emergency -lamp

-control

controlcommands

Length

(ET&)

4

5

6

8

450

400

683

950

14

23

1750 5900

10300

11

(a) Sacerdoti’s method

W

Fig. 9. Composed MENDEL 0BECT”s which correspondto the functional model.

[building(l,2 ) , building(2,3),building(3,4), building(4,5),# information on building building-status(l1,sdf e ) ,building-status(l2,s a f e ) , building-status(l3,saf e ) , # lift security liftwaitng(ll,2),li ftwaitng(l2,2), lif twaitng(l3,2), # lift status door-status(Z1, open), door-status(l2, open), door-status(l3, open) # door status] [goal: lift 1 goes floor 5 and lift 2 goes floor 11 is described as [requests(ll,5), requests(l2, l ) ] From the above specification, we can obtain a set of OBJECT’s as follows. (b)Our method [o3,o5,o9,oi’,08,010]. After several specifications are given to planning, 1) complete library and 2) a correct construction mechanism several OBJECT’s are retrieved and composed are needed. Regarding the library, however, it is very difficult finally, as shown in Fig. 9. In Fig. 9, OBJECT’s to prepare the complete library before the construction. Thus, 01, 02, 03, 04, 05, 06, 07, 08, 09, and 010 are,retrieved when the system cannot find an OBJECT, it is necessary for the and composed by planning. The names of the individual designer to analyze the incomplete plan and to investigate the OBJECT’S are as follows: 01: Security-control, 02: Li f t-call, 03: Doorstatus, causes. In our planner, the designer can investigate the failure by using the abstract plan which corresponds to the skeleton 04: Register, 05: Lamp-panel, 06: Door-controller, 07: of the final plan. Regarding the construction mechanism, our Scheduling-database,08: Scheduler, 09: Door-sensor, and planner is based on the traditional Strips planner which has 010: Motor. Fig. 10 shows the METHOD description of example of “06: been proven to be a sound logical system. Thus, our planner can always make the plan satisfy the requirement specification. Door-controller.” HI. SUPPORT TOOLS FOR THE PROTOTYPE EVALUATION STEP D . Applying to a LIFT-control System The proposed method has been applied to a LIFT-control system (an elevator-control system) which was actually im- A. Overview The composed OBJECT’s in MENDEL form a queuing plemented on multi-microprocessors. Each of the reusable components is implemented as an OBJECT in MENDEL, and network, where each OBJECT in MENDEL represents a server planning constructs the set of OBJECT’s to satisfy the goals and each message in MENDEL represents a transaction. The statistical data collected during prototype execution are passed from the initial condition. The requirements specification, which represents the initial to the prototype evaluation step to be analyzed. In the prototype evaluation step, any bottleneck sources conditions and the goals to be achieved, is shown below. As mentioned earlier, we must give the specification (initial should be detected rapidly and appropriate performance imcondition) for the input data and specification (goal) for the provement plans for the bottlenecks should be generated. In particular, the reduction of prototyping costs depends on output data. For example, the ability to produce improvement plans. In other words, [initial condition: There exist three lifts, 11,12,13 in a 5-storied building. The the prototyping evaluation step should accomplish appropriate operational environment for these lifts is to be safe. All lifts parameter tuning to reduce prototyping costs. In performance design, there are a large number of parameare in a standby state at floor 2 and the doors are open. 3 ter candidates to be tuned. A knowledge engineering technique is described as


IEEE TRANSACTIONS ON SOFIWARE E N G I “ G ,

856

METHOD ml(door?[No, Type, Width, Height], command![No, Next, F]) -> 0 < Width < 1000, 0 < Height < 2000, Type=’CO’ 1 isstatus (No, Current, Next), Vmax is Width / 10, A is 0.5, D is 2.0, FO is Width * Height * D * A, F2 is Width * Height * D * A * (-1), TO is Vmax / A, T1 is W / Vmax, T is Vmax / A + W / Vmax, F = [[FO, 0, TO], [0, TO, Tl], [F2, T1, TI]. METHOD m2(door?[No, Type, Width, Height], command![Ko, Next, F]) -> 0 < Width < 1000, 0 < Height < 2000, Type=’SCO’ I isstatus (No, Current, Next), Vmax is 100, A is 1.0, D is 4.0, FO is Width * Height * D * A, F2 is Width * Height * D * A * (-1), TO is Vmax / A, T1 is W / Vmax, T is Vmax / A + W / Vmax, F = [[FO, 0, TO], [0, TO, Tl], [F2, T1, TI]. METHOD m3(door?[No, Type, Width, Height], command![No, Next, F]) -> 0 < Width < 1000, 0 < Height < 2000, Type=’lS’ I isstatus (No, Current, Next), Vmax is Width / 20, A is 0.5, D is 2.0, FO is Width * Height * D * A, F2 is Width * Height * D * A * (-1), TO is Vmax / A, T1 is W / Vmax, T is Vmax / A + W / Vmax, F = [[FO, 0, TO], [0, TO, Tl], [F2, T1, TI]. METHOD m4(door?[No, Type, Width, Height], command![No, Next, F]) -> 0 < Width < 1000, 0 < Height < 2000, Type=’2S’ I isstatus (No,Current, Next), Vmax is 50, A is 1.0, D is 4.0, FO is Width * Height * D * A, F2 is Width * Height * D * A * (-l), TO is Vmax / A, T1 is W / Vmax, T is Vmax / A + W / Vmax, F = [[FO, 0, TO], [0, TO, Tl], [F2, T1, TI].

Fig. 10. The METHOD description example of OBJECTDoor-controller.

based on qualitative and quantitative reasonings is adopted for non-experts to select appropriate parameters. These reasoning methods can be designed by modeling the performance design experts’ reasoning process. We have developed two knowledge-based expert systems on the basis of heuristics and knowledge obtained from experts, BDES (Bottleneck Diagnosis Expert System) and BIES (Bottleneck Improvement Expert System) [21], [22], [24]. BDES qualitatively diagnoses or identifies bottlenecks and their sources, and generates a qualitative improvement plan. BIES quantitatively estimates the effects of the improvement for bottlenecks and their sources on the whole queuing network. BDES and BIES are based on qualitative reasoning and quantitative reasoning, respectively. Several kinds of queuing networks have been utilized in various applications [27]. Two major categories are open and closed types. In each category, a typical example is the synchronized type of queuing network. We have also developed BDES-S (BDES for open Synchronized queuing network) and BIES-S (BIES for open Synchronized queuing network) [23]. In this section, we describe BDES in detail. In addition, Appendix A describes BDES-S and Appendix B describes BIES and BIES-S, respectively.

B. Per$ormance Parameters The .following are the performance parameters. A: The average number of messages arriving at a server per unit time (arrival rate). p: The average number of messages that can be processed by the server per unit time (servicing rate). t: The average number of messages coming out of the server per unit time (throughput). p: The rate of time in which the server is actually processing messages (utilization rate).

Fig. 11.

Case of X

VOL. 20, NO. 11, NOVEMBER 1994

< p. P

1 *

q

I Fig. 12. Case of X

2

ii

p.

q: The average number of messages waiting for processing

in front of the server (queue length). The branching probability of messages from a server. In Fig. 11 and Fig. 12, when X and p are given, p and t representing the performance of the server are determined depending on which is greater between them. Fig. 11 shows an example where the arrival rate is smaller than the servicing rate. The average of the inter-arrival time (1/X) is greater than the average servicing time (Up). In this case, the server can continuously process messages without delay. The throughput (the amount of messages coming out of the server) is equal to the arrival rate of messages at the server. The utilization rate, p , is as follows. p =(Average servicing time)/(Average inter-arrival time) T:

=(l/p)/(l/X) =X/p

Fig. 12 shows an example where the arrival rate is greater than or equal to the servicing rate. The average inter-arrival time is smaller than or equal to the average servicing time. In this case, the server cannot process all of the arriving messages without delay. That is, the next message arrives at the server while a message is being serviced. The throughput from the server is equal to the servicing rate of the server. The utilization rate is p = 1 (The server is always working.).

C . Bottlenecks A queuing network is a network connecting multiple servers. In a queuing network, a server with p = 1 is a bottleneck. The queue for a bottleneck server probably grows infinitely. If a bottleneck server exists, the queuing network falls into an unstable or overloaded state. A server with p not close to 1 but excessive p may possibly become a bottleneck. If a great deviation is seen in the dispersion of X or p of a server, its queue may rapidly grow even if p is not close to 1. Based on experience, the concept of “failure to safety” is often used to determine that a server with p 2 0.7 may become a bottleneck. Although there is no excessive p (the result of a short-term measurement), a server with an excessive queue length may


~

HONIDEN et al.: APPLICATION OF ARllFICIAL INTELLIGENCETO OBJE(;T-ORIENTED PERFORMANCE DESIGN

I

\

Fig. 13. Measurement for TCSS13 (terminationtime: lOO000).

have an excessive p when an excessive amount of messages arrive after the measurement is over. Although the excessive queue length may be gradually reduced afterwards, the concept of “failure to safety” to prevent bottlenecks from occurring determines that a bottleneck may occur in servers with q 1 at the time of measurement. In M/M/1 (Poisson arriva4exponential service) type of server, the equation, q=p2/(1-p), holds at a stable state. Our objective queuing network may consist of non-M/M/l type servers, may be in an unstable state, or may not be measured for a long time period. Therefore, distinct bottleneck landmarks, both p 0.7 and q 2 1are provided from the “failure to safety” aspect.

>=

>

D. Difslculty in Parameter Tuning A tuning plan (or several tuning plans) to improve a bottleneck consists of one or more altemative or selective solutions in which the parameters to the queuing network are adjusted to make p < 0.7 under the condition that only the queuing network configuration remains fixed and all of the parameters are variable. It is assumed in TCSS13 shown in Fig. 13 that the configuration is fixed, and the amount of messages entering from outside, the branching probabilities from the servers, and the p of each server are known. p , t, and X can be obtained by actual measurement or simulation. In this example, they were obtained by simulation. Parameter tuning is then performed to improve bottlenecks provided that the queuing network configuration is fixed. In TCSS13, servers which may become bottlenecks are s10 and 917, each having p 0.7. s10 is used as an example to show an improvement. One of the following actions can be taken in s10 to reduce the p of s10 to lower than 0.7: 1) increase p10, or 2) decrease NO, subject to (new p10) = (new XlO)/(new p10) < 0.7. where, p l 0 means p of s10, A10 means X of s10, p10 means p of s10. Taking only the above actions is insufficient in a queuing network where several servers are connected. When the action mentioned in 1) is taken, messages which were likely to remain in the queue of s10 due to the high p will receive more services from s10 than before. As a result, t10 (i.e., t of s10) is increased, A13 immediately below s10 is increased, and the

>

857

A’s at the servers below 913 are also increased. In tum, the p’s of servers which are present downstream of s10 will further increase, and the servers that were not bottlenecks may have the possibility of falling into bottleneck states. To carry out the action mentioned in 2) above, one of the actions below should be taken while examining the servers upstream of 310, along the path from 310 to the entrance of the queuing network. 2-1) Reduce the branching probabilities from the several servers, or 2-2) reduce the amount of input messages entering from outside. To carry out the action mentioned in 2-1), if several branch points are present on the path leading to the upper stream, the branch point where T should be reduced must be determined. On the path from s10 to its upper stream, there are two branch points s l and 94. Since the other branch probability increases at the branch point, causing X at the other downstream to increase, attention must be paid not to make bottlenecks in the other downstream. Definition: Sequential Computation of p and t: If the configuration of a queuing network (how servers are connected), the amount of input messages from the outside, the branching probabilities from the servers, and the p of each server are known, A, p , and t for each server can be sequentially determined, as shown in Fig. 11 and Fig. 12 with the server into which messages enter from the outside being set as the starting point. If X < p, then X = t, as shown in Fig. 11. If X 2 p, then p =t, as shown in Fig. 12. p is also determined. If sequential computation is used to obtain a tuning plan, the expression is set up using the parameters appearing in l), 2), 2-1), and 2-2) above as its variables. The expression contains a product term using several T ’ S shown in 2-1) as its variables. Since p should be lower than 0.7 after the improvement, the expression of p= X/p < 0.7 must hold for all servers. The expression is a nonlinear simultaneous equation or inequality. The simultaneous expression often tends to be enormous and takes much time to solve. Generally, a typical system to which a qualitative reasoning method applies has the following feahues: 1) the details of its behavior are unclear and an expression such as a differential equation to represent its behavior is unknown, or 2) its behavior is known to some extent, but the expression to represent the behavior is complex and enormous, so the solution is unknown, or the solution requires much time. The queuing network has the feature mentioned in 2) above, so a qualitative reasoning method applies effectively to parameter tuning for a queuing network.

E. Bottleneck Landmark Experts’ heuristics say that 0.7 can be used as the bottleneck landmark (BL)for p, and 1 can be used as the bottleneck landmark for the queue length (QBL).If p 2 BL or q 2 QBL,experts judge from the “failure to safety” aspect that the possibility of a bottleneck exists.


858

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 20, NO.

[p] and [q] represented in qualitative reasoning notations are qualitative values (+,0, -) measured from BL and QBL, respectively. [p] = +: This expression means p > BL. A bottleneck may occur. [q] = +: This expression means q > QBL. A bottleneck may occur. dx (where x is the performance parameter such as A, p) represented in a qualitative notation is also the differential of x as follows: dx = increase of x; dx = -: decrease of x; dx = 0: x does not change.

+:

F. Qualitative Expression for the Server The behavior of a server can be represented by a qualitative expression. One of the characteristics of the expression is that the type of expression varies depending on whether a bottleneck may occur or not. The following expressions are referred to as qualitative behavior expressions (QLBE) for servers. In the case that a bottleneck may occur, the expression is specially referred to as a qualitative bottleneck improvement expression (QL-BE). The format for qualitative expression is as follows: dx = c dy = [y]. (The right-hand side of “t” expresses the cause in a qualitative behavior while the left-hand side of “+”expresses the effect.) This expression means that the performance parameter x changes by a change in the performance parameter y. A change in x is represented by [XI (i.e.. 0,-) and that in y is represented by [y] (i.e., -). For example, dp = + d p = means that p increases when p increases. a) QLBE (QuaLitative Behavior Expressions) b) When p < BL (when X < p), the situation corresponds to the server in Fig. 11. a-1) For X dp = f t dX = f : X and p change in the same direction; i.e., when X increases, p increases, when X decreases, p decreases. dt = f c dX = f : X and t change in the same direction. a-2) For p dp = c dp = f : p and p change in the opposite direction; i.e., when p increases, p decreases, when p decreases, p increases. dt = 0 t dp = f : t is not affected by a change in p; i.e., although p changes, t does not change. QL-BE (QuaLitative Bottleneck Improvement Expression) When p 2 BL (when X 2 p) or q 2 QBL, the situation corresponds to the server in Fig. 12. b-1) For X dp = - dX = - : p decreases when X decreases. dt = 0 t dX = - :t is not affected when X decreases. b-2) For p dp = - t d p = : p decreases when p increases. dt = + dp = t increases when p increases.

[XI

+

+

+,

+ +:

+,

+

11. NOVEMBER 1994

for i= { s10, s17) (which may be bottleneck) qualitative state: [ p i] = dpi = QL-BE: d p i = - +dAi= -

+

+

d t i = 0 +dAi= d p i = - +dpi= dpi= + d p i = 4subtotal : 8 expressions = 4 expressions X2 (servers)

+

for j= { sl, s2, s3, s4, s5, s6, s7, s8, s9, s l l , s12, s13, s14, s15, s16, s18) qualitative state : [ p j] = QLBE:d p j = k + d A j =+ d t j=k+dAj=k j =* d p j = *d d t j= 0 +dpj=f subtotal : 128 expressions = 8 expressions X 16 (servers) 1

.

total : 136 expressions Fig. 14. QLBE’s and QL-BEs for all servers of TCSS13.

b-3) For q dq = - t dp = -: q decreases when p decreases. dp = - t dq = -: p decreases when q decreases.

G. Qualitative Tuning Using No Heuristics As mentioned in Section III-D,changing X of a server requires changes in the t’s of its upper servers. Increasing t of a server leads to an increase in X of its downstream server, resulting in a possible bottleneck. Combining several qualitative expressions set up for all servers and solving them is one way of tuning. With regard to TCSS13 in Fig. 13, Fig. 14 shows the QLB E for a server in which a bottleneck may occur and also shows the QLBE for a server in which no bottlenecks occur. In Fig. 14, the number of expressions used for TCSS13 is 136. Improving a bottleneck requires to treat these expressions and the 112 qualitative expressions for VO shown in Fig. 15. However, using the qualitative reasoning method to solve the combination of all these expressions is not effective, because the number of states may explode.

H . Qualitative Tuning Using Heuristics The problem should be solved by using experts’ heuristics (shallow knowledge), not by using the combination of all expressions (about 250 expressions). Experts’ heuristics refer to a qualitative bottleneck improvement expression which rep


a59

HONIDEN er 01.: APPLICATION OF ARTIFICIAL INTELLIGENCE TO OBJECI'-ORIENTED PFRFORMANCE DESIGN

TABLE III EXAMPLE OF SIJBS~IJCIWRE BMFD KNOWLEOGE AND QL-BEs ADOPTED BY BDES ~

substructure

knowledge

QL-ELE

The serverswhose p'sLO.7 or whose q's>l.O may be bottleneck. 2

%-&,.,

+-J@

p,,hph

p,

,-

On improving a bottleneck 51 by increasing its p . decrease p h of its downstreamserverswhose p t s L0.7 or whose qi's>l .O.

3: tandem

%3@->,A& P'

derease ti. for decresing p z

dpi-+dpl=+ dpj=t d

j=-

,jp2=-&I.=-

P * : W

Fig. 15. Qualitative U 0 expressions for servers.

resents the increase or decrease in the performance parameters for each partial configuration in which servers are connected. We used the qualitative bottleneck improvement expression to develop the Bottleneck Diagnosis Expert System (BDES) which enumerates tuning plans based on qualitative reasoning. BDES contains several types of knowledge for bottleneck improvement on such as downstream, tandem, joint, branch, and loop substructures.With this knowledge, the number of parameters which must be handled decreases substantially compared with the method in which all parameters are equally handled. Examples of the knowledge and QL-BIE's in Table 111 reveal that, if we focus our attention on the substructures of a queuing network, the number of performance parameters is considerably reduced compared to the case where we discuss all server parameters. For example, if server 93 which receives its throughput from a loop has the possibility of being a bottleneck, as shown in "7:loop" of Table 111, we can improve it by reducing only the amount of arrivals at the loop instead of reducing the performance parameters within the loop (see knowledge 7 in Table III). The knowledge and the qualitative bottleneck improvement expressions in Table 111 are called experts' shallow knowledge. The qualitative behavior expressions, the qualitative bottleneck improvement expressions, and the qualitative VO expressions for each server mentioned in Sections 111-F and III-G are called deep knowledge. The shallow knowledge mentioned in this section can be proved by the deep knowledge. Fig. 16 shows the qualitative parameter tuning process in BDES with regard to bottleneck server 917 in TCSS13 shown in Fig. 13. Compared with Figs. 14 and 15, the number of expressions used in Fig. 16 is substantially reduced to suppress the explosion of the number of states. Block 1 at the top of Fig. 16 is the tuning goal (dp17 = -) for the improvement of bottleneck 917. The branch from Block 1 to Blocks 2 and 3 is the result of applying the qualitative bottleneck improvement expression to 917. Block 2 is the knowledge concerning the loop. Block 2 shows that only p17 and t12 are used in the loop consisting of 915, s16, and 917. The result of qualitative reasoning shows that at dashed Blocks 4, 10, 19,21,22 there exist altemative and selective Qualitative Tuning Plans which achieve the tuning goal (dp17 = -). 1. Applying to a LIFT-control System

In this section, we use the same example as mentioned in Section 11-D.

xm

5 :branch

If knowledge-2 is applicabel to s3 and it's downstream server@). dpz--

(2) when r is not modifiable. decrease 11 for decreasing p z .

pa

I

1 0 2

PI

DS

o \o.!;

d pz=-dtl=-

it is senseless to becrease

: hmh

Decrease t for decreasing t 2.3 (output of a loop).

dp3=-

Decrease t

dpz=-

-dt.=-

pr:high

for decreasing p 2 .

-dtm=

In Phase1 of OOPD, the composed OBJECT'S in MENDEL form a queuing network; each OBJECT in MENDEL corresponds to a server and each message in MENDEL corresponds to a transaction. It is assumed that each OBJECT is assigned to a separate processor in a multi-processor system which consists of 10 micro-processors, as shown in Fig. 17. p of each server depends on the type of the micro-processor. OBJECT'S 01, 02, 03, 04, 05, 06, 07, 08, 09, and 010 are assigned to s l , 92, 93, 94, 95, s6, 97, s8, s9, and s10, respectively. Building-status, li f t-status, and door-status correspond to the external inputs to s l , 92, and 93 (called ga, gb, and gc), respectively. Fig. 17 also shows the performance data from prototype execution. For example, the arrival rate of building-status was 0.06 s and s7's utilization rate was 0.80 which showed a bottleneck. Emergency-button and emergency4amp-control were omitted from this queuing network because they did not qualifj as statistical measurements. In the queuing network in Fig. 17, p's for all servers, A's for the entries into the network, r's, and the network structure were given from the prototype construction step before the prototype execution. p's, t's, q's, and A's for all servers were able to be obtained by prototype execution. The designer/user can determine and locate bottlenecks by BDES. Fig. 18 shows a list of servers and their p values created by BDES. In the example in Fig. 18, the designer/user selected bottleneck 97. Qualitative simulation was applied for improving the bottleneck on 97. Then, BDES diagnosed the


860

IEEE TRANSACrIONS ON SOmWARE ENGINEERING,VOL.

20, NO. 11, NOVEMBER 1994

Server with maximum p: (s7 300) Please input the name of the server for diagnosis.

I

: 47

BDES shows the results of bottleneck diagnosis. Parameter t o be improved for decreasing p of s7. *plan-1 increase p ( s 7 ) *plan-2 decrease r(s2,s4) *plan-3 decrease external input, gb *plan-4 decrease external input, ga

on joint

on joint

Fig. 18. Improvement plans generated by BDES diagnosis.

66,611,612~

emergency button buildingstatus on joint

l4

on branch external input 181 d t i = -

v c d b=o&try

P!!an4 ....................

on branch

d t is= - -d r 1 s 17 d t l s - -dolo=-

e * d

1 input

on branch ...........

p;dp17="

-dri,s=-

20

dtz--

i

1 -dga=-

oamq

P F . . ...................

ISi d t . ! ~ . = . ~ , . c d p o , - :

:dpl7=._...-dsb=-.j

-control

lift-status controlcommands

61, s3.d

'

67 7 1 dt2,7=-62. d. dt2=- I

emergency

-lamp

22

'

doorstatus Fig. 19. Modified MENDEL OBJECT'S organization.

IdR!L~.~...-dUa.=.r.i

TABLE IV

RA"AND QUEUE LENGTHBETWEEN "WO MEAS~"TS Before tunin After tunin

COMPARISON OF UTILIZATION

Fig. 16. Qualitative tuning on bottleneck server 17. Server

r(s2,s4) 0 780

+iIp 2 40

0 64

0 75

ga

The designerhser can redo the measurement using the new parameters, obtain a new measured quantity, and compare the second quantity with the first. Table IV shows a comparison between the p values obtained by the first (before tuning) and second (after tuning) measurements. Table IV shows an appropriate improvement for the bottleneck. In Phase2 of OOPD, the effect of synchronization on the Fig. 17. Queuemg network mapped from MENDEL OBJECT'S m Fig. 9. performance of concurrent programs must be examined. By refining each OBJECT, in the example in Fig. 19, the designer sources of the bottleneck 97 and produced four bottleneck finds that in 010; one METHOD which receives the message improvement plans, which were altematives for the bottleneck from 09 starts only after another METHOD receives the message from 08. 010 is assigned to 910 in Fig. 20. Then, s10 97. For this example, the designer/user selected plan-2. must manage the synchronization problem between messages For plan-2, BIES quantitatively improved the parameters as from both s8 and s9; so it may be a bottleneck server. shown below. BDES-S and BIES-S are able to model such s10 as a r(s2,s5) 0.300 + 0.780 MERGE server and can generate an improvement plan for r(s2,s4) 0.700 0.220 s10. Fig. 20 shows the performance data such as p, A, and In order to improve the bottleneck of 97, BIES quantita- t from prototype execution. BDES-S diagnoses the sources tively modified T from s2 to 94. Fig. 19 shows the modified of the bottleneck s10 and produces improvement plans for MENDEL OBJECT'S organization according to the BIES's bottleneck improvement such that both queue lengths should improvement plan. In Fig. 9 and Fig. 19, the pipe from 02 to be balanced, these plans are altematives for the bottleneck 04 is replaced by the one from 02 to 05. The change in the s10, as shown in Fig. 21. message distribution suggests that the OBJECT'S 04 and 05 Table V shows the qualitative improvementplans and quanshould be re-designed. In MENDEL, part of the message from titative improvement plans. In order to improve the bottleneck 02 to 04 should be changed to 05. of s10, some plan names to be selected were decided by

+


86 1

HONIDFIN et al.: APPLICATION OF ARTIFICIAL INTELLJGENCE TO OBJECT-ORIENTED PERFORMANCE DESIGN

Server Plan name Plan type

--

0.075 130.15

Quantitative Qualitative improvementplan improvement plan

SlOLD1 large A

dgC=-

gc 0.161-0.085

SlOSI1 small A

dga=+

ga 0.059-0.135

-+

r2,4 0.7-0.2

SlOBD1 both A

+-

Fig. 20. Queueing network mapped from MENDEL OBJECT’Sin Fig.19.

SlO

--

S1OBD2 both A

ga 0.059-0.025 gc 0.161-0.049

dga=-

S1OBD3 both A

Parameter to be improved for s10. *plan-1: Decrease larger A. 1. decrease r(s2,s5) *plan-2: Increase smaller A. 1. increase r(s2,s4) *plan-3: Decrease both As 1. decrease r(s2,s4) and external input, gc 2. decrease external input, ga and gc 3. decrease external input, gb and gc *plan-4: Increase both As 1. increase r(s2,s4) and external input, gb 2. increase external input, ga and gb

gc 0.161-0.979

+-

SlOBI1 both A

-+

SIOB12 . both A -4-

dR,4=+ dgb=+

r2,4 0.7-0.9 gb 0.065-0.1275

dga=+ dgb=+

ga 0.059-0.125 gb 0.065-0.09

Input and output specification by designer

Fig. 21. Improvement plans generated by BDES-S diagnosis.

the designer/user. However, the extemal inputs, that is, ga, gb, and gc, could not be modified because they were given specifications. So, in this case, the designerber could select only SlOLDl or SlOSIl. Both plans indicated the modification of r from 32 to 34. In Phasel, r from 32 to 34 was modified. This modification suggested that the OBJECT’S 04 and 05 should be re-designed; that is, the METHOD in 04 should be moved to 05. On the other hand, in Phase2, this modification suggested to the designer/user that the METHOD which was moved from 04 to 05 in Phasel should be re-designed to satisfy the modified value.

Connected OBJECTS (each OBJECT has processing to be mappedto sewers volume and branching probability) imulation condition of input messages from outside and hardware architecture)

1

Simulation results ( p , t, A , qof each OBJECT) Data generator for BDES or BDES-S

4

Designeduser

Iv. USING SUPPORT TOOLS A. System Configuration

This section describes the configuration of our system and the system/designer/user interaction. Our system mainly supports the designer. The user’s role in the system is the assistance which helps the designer’s decision. The system consists of five subsystems as shown in Fig. 22 which illustrates the overall configuration and the flows of data between the five subsystems. From the viewpoint of prototyping described earlier, constructing a prototype corresponds to OBJECT retrieving and composition, executing a prototype corresponds to simulation, and evaluating a prototype corresponds to data generation, BDES, and BIES. Planning is used to retrieve and compose the OBJECT’S that satisfy the input and output specifications given by the designer. Each OBJECT has information about the processing

1

I

t

Designeduser Quantitative parameter tuning plan

4

(tuning functional design by designer) Fig. 22. System flow with designerhser interaction in OOPD.

volume and the branching probability by pre-simulation or estimation as a unit server. The servicing time of each OBJECT can be defined as follows.

Servicingtime = 1/ [processingvolume]/ [processorpower]. (The processing volume can be obtained by actual measurement or by estimation. The processor power indicates the power of the processors within the multi-processors.)


862

IEEE TRANSACTIONS ON SOFlWARE ENGINEERING, VOL. 20, NO. 11, NOVEMBER 1994

S e w Then, the retrieved and composed OBJECT’s which have in average 14 sec SeMC8 been defined as executable specifications are simulated by reDeparture in in average 14 sec Arnvalin awrage 1 4 m garding them as a queuing network. To perform the MENDEL P-1 (a) Example of bdtleneck server simulation, the conditions such as the amount of input mesIn SeMC4 sages from the outside and the hardware architecture should in average 7 sec be specified. SeMW ~ n i v in a ~‘J L b m p a r t u r e in in average 14 sec average 10 sec average 10 sec The results of the simulation represent the parameters of the P-07 (b) Increment of s e ~ ~ capaklw n g (d)lmprovementby parallel processing queuing network, including the arrival rate, utilization rate, SeMce SNlW queue length, and throughput of each server. The results of in average 7 sec in average 7 sec the simulation provide input data to BDES. The input data to Arrival in + Departure in average 1Osec average I O sec BDES are all of the parameters of the queuing network. BDES p 4.7 p-0.7 informs the designeduser of servers with high utilization rates, Departure in average 10 sec and provides him with improvement plans for some of the high (c) Improvement by pipeline processing utilization servers that are selected by him. The designeduser can select some tunable plans from the proposed improvement Fig. 23. Improvement of bottle neck server. plans and put them into BIES. BIES generates a quantitative improvement plan, and the designer can use it to improve the how to pipeline 2 servers when a task requiring 14 s can be functional design. divided into 2 serial tasks, each requiring 7 s. In Fig. 23(d), an The following is a summary of the designer’s role. additional server requiring 14 s to perform the task is prepared Gives the input and output specifications which are used and used to divide the arriving messages into 2 groups with to retrieve OBJECT’S. To improve the accuracy rate the same branching probability. of OBJECT retrieving, a thesaurus should be prepared The following describes a tuning plan from the viewpoint of for the names which appear in the input and output MENDEL; in other words, how to adopt a tuning plan to the specifications. The thesaurus defines a similar meaning functional design. Since 1) indicates changes in functions, it of names or upper concept among the names. Note that cannot be changed as a parameter. If no change exists for 2) or this thesaurus is not essential. 3), and if changes for 1) exist, no configurationcan satisfy the Specifies the conditions for simulation, such as the functions under the specified hardware architecture. To achieve amount of input messages from the outside and the 2), the designer can change the paths of the messages which hardware architecture in conjunction with the user. flow between the OBJECT’S. To cope with a large change, Informs BDES of the server which should be improved he can change the assignment of the desired METHOD from in conjunction with the user. one OBJECT to another. To cope with a small change, it is Selects the most appropriate improvement plan in con- necessary to divide a METHOD and to rearrange the divided junction with the user. METHOD’S. Tunes the functional design by the contents of the imTo achieve 3), the designer can adopt the following improvement plan. provements. Each of them is described from the viewpoint of functional design. It is also assumed that no change is made B. Tuning the Functional Design in the hardware configuration. 3)-a Enhancement of service capability The following discussion summarizes how to apply the 3)-b Pipeline processing improvement plan to tuning the functional design. 3)-c Parallel processing A tuning plan as a queuing network consists of the following actions: Enhancing the service capability without altering the per1) Reduce the amount of input messages from the outside. formance of the server can be achieved by reducing the processing time. Reduction of the processing time can be 2) Modify the branching probability. achieved by using another OBJECT which provides the same 3) Increase the servicing rate of the server. 1) Indicates a decrease of the load on the system; 2) function, or by &proving the actual implementation method indicates a partial change in the path through which messages of the current OBJECT. Pipeline processing indicates the following changes. When servers are COMeCted in tandem, flow. A change of the branching probability leads to a change of functions implemented within the server should be divided and moved to other servers unless the utilization rate of any server the load on each path and thus 2) can be achieved. As for 3), an example is given on reducing the p of a becomes too high. Parallel processing indicates the following server to 0.7 to improve the bottleneck server a shown in Fig. changes. If the server in question has a branching point just 23(a). In Fig. 23(b), the same task is performed by replacing above it and a conjunction point just below it, and if the the existing server with a server having twice the servicing utilization rate of the other branch destination server is not time (i.e.. half the servicing time). In the case that such a so high, the functions of the server in question should be server replacement is unrealistic, making the servers pipelined decomposed and moved to the other server. If the changes mentioned above cannot be implemented as shown in Fig. 23(c) or making the servers parallel as shown in Fig. 23(d) are realistic alternatives. Fig. 23(c) shows due to restrictions of the functional design, the hardware ---)

-LIa 3+


HONIDEN et al.: APPLICATION OF ARTIFICIAL INTELLIGENCE TO 0BJU)T-ORIENTED PERFORMANCE DESIGN

configuration cannot satisfy the required functionality and performance. In this case, the designer can go back to planning to construct an alternative prototype. Other possible actions, such as the improvement of processor performance, may be sought within the restrictions of the hardware configuration. V. RELATEDWORK

a63

that are generated in a higher space. MENDEL uses input and output specifications when connecting a set of OBJECT’S. There has been much work in this area during the last few years such as Inscape [36]. Inscape enables the user to search the system database and find one or more objects through their pre- and postconditions. The context of these conditions are similar to the specification of our OBJECT’S. However, Inscape uses these conditions for interactive or incremental system construction, while our system uses these conditions for automatic construction. In addition, Inscape finds the object by means of a simple predicate matching, while our system finds the OBJECT candidates by using abstraction hierarchy and means-ends analysis. Therefore, in large system database (i.e., object library), our system can efficiently find the OBJECT’S from the database. For plan-based program construction, the Programmer’s Apprentice [41] is a typical example although it does not address real-time programs and does not adopt planning. Fourth, as for program adaptation, several researches have been presented such as [43], [28]. The characteristics of our method compared with others is that tuning the functional design is done by performance evaluation. RESAS provides performance/reliability analysis in dynamic adaptation of realtime software [3]. Since it is possible to describe a qualitative relation between performance and reliability, our method can be extended to do performance/reliability tradeoff analysis. Fifth, as for qualitative reasoning, the relation to queuing theory and the main difference from other work should be discussed. The general analytical method based on queuing theory generates p’s, t’s, and A’s for all servers, using given A’s from the extemal, and all given p’s and T ’ S . On the other hand, BDES and BIES generates some p’s and some T ’ S in order to improve the bottleneck, using given p’s, t’s, and A’s for all servers. Several applications of qualitative reasoning to a design process have been proposed, e.g., 1381, [471. The difference from other work in applying qualitative reasoning to software engineering, e.g., [9], resides in the prototype evaluation step, where qualitative reasoning is indispensable to effectively implement human heuristics in performance design. Furthermore, no related work on the queuing network model has been presented in the qualitative reasoning domain.

This section compares the method presented in this paper with other related work. The principal characteristics of the presented method include those of OOPD, the methodology employed in the prototyping process, MENDEL as an executable specification language and rapid prototype construction tool, program adaptation, and qualitative reasoning used for the prototype evaluation method. First, while several tools based on object-oriented design have been presented, few of them support performance design as does OOPD. Second, the presented prototyping process has two characteristics; the application domain is limited to performance design for real-time systems on multi-processor systems, and special emphasis is put on the prototype evaluation step. Our method is considered to be general-purpose and applicable to several other domains in which the prototype evaluation step is needed for a more complex system. Various prototyping methods for real-time systems have been proposed, e.g., [29]. However, these methods do not support the overall performance design for statistical features. No prototyping method which emphasizes the prototype evaluation step has been presented except for CAPS [30]-1331. CAPS supports the prototype evaluation step. CAPS,through developer/user interaction while executing the prototype in the Execution Support System, provides not only the means for prototype evaluation, but an opportunity to explore, implement, and test system improvements during the evaluation step. The main difference between CAPS and our method is that our method supports the performance improvement task. Third, as for MENDEL, two points, the executable specification language and planning, should be discussed. Various executable specification languages have been presented and experimentally used. They are classified into two groups: the operational approach, such as GIST [5] and PAISLey [48], and the functional approach, such as MODEL [37] VI. CONCLUSION and RF’S [6]. MENDEL employs the operational approach. This paper has described the role of artificial intelligence One of the executable languages most similar to MENDEL is PLEASE [45] which is predicate logic based. The main in implementing a prototyping process in performance dedifference from MENDEL is that PLEASE allows a procedure sign for real-time systems. The proposed method has several or function to be specified using pre- and post-conditions limitations and assumptions as follows. written in predicate logic. Concerning the combination of 1) In planning, our method cannot cope with a problem actor-model and declarative knowledge representation, one of which has any dependency relationship between goals the languages most similar to MENDEL is Orient 8 4 K [20], (i.e.. a non-linear problem), since sub-goals which have which is an object-oriented concurrent programming language. already been solved may be violated. For problems The main difference between MENDEL and Orient 84K is in which no dependency relationship is assumed for that Orient 84K has several message-scheduling mechanisms the given goals, our OBJECT’s composition method is and a parallel control mechanism as a programming language effective in reducing the spaces that should be searched and does not support a hybrid inference engine. As for for problem solution. planning, MENDEL’S planning ability takes less computation 2) The limitations in a queuing model are as follows. time than Sacerdoti’s method [42]. The difference between the computation time is a result of the effectiveness of the plans 2-a) Dynamic object creation is not permitted.


IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 20, NO. 11, NOVEMBER 1994

864

2-b) A closed type queuing network is not supported. 2-c) When required messages are received, OBJECT execution is started without waiting for the completion of another OBJECT execution. 3) In qualitative reasoning, the average time is only considered. Then, we cannot treat hard real-time constraints. Among the above points, 2-c) and 3) may be the most critical limitation from the viewpoint of applicability. As for 2-c), in MENDEL execution, it is assumed that individual OBJECT’s are assigned to individual processors in a multiprocessors system. In practice, several OBJECT’s may be mapped to the same processor; so, we are now implementing a hierarchical queuing network version in order to solve this problem. As for 3), we plan to extend our method to handle hard real-time constraints by expressing qualitative behavior which takes into account the variance of the performance parameters. We are also investigating an on-line performance tuning method where we monitor the queue length and enhance the performance by changing performance parameters for dynamic scheduling [35], [39]. Regarding system scalability, we must mention the following three viewpoints. 1) MENDEL language description ability. MENDEL is an object-oriented language which provides us with high modeling ability for larger systems. 2) Planning ability. Our planner can currently synthesize nearly 30 OBJECT’S. However, if our planner is applied to larger systems, it will require more search space and time. We hope to continue our research on 1) making more useful abstract hierarchies and 2) adding information (e.g., resource usage) to the OBJECT’S. 3) BDES ability. We actually applied BDES to larger system where about 50 servers and more than loo0 transactions exist in a queuing network. APPENDIX

A. BDES for an Open Synchronized Queuing Network (BDES-S) BDES-S diagnoses bottlenecks and their sources by reviewing a synchronized queuing network and all its parameters. A synchronized queuing network is composed of the following four types of servers, as listed in Table VI. 1 . NORMAL. Server: A NORMAL server provides one output path for one input path. An arriving entity enters the server according to the first come first served (FCFS) rule and leaves the server after a finite time period. This server can represent the execution of an OBJECT. 2. SPLIT Server: A SPLIT server is a synchronized server with two output paths for one input path. An arriving entity enters the server according to the FCFS rule and produces a clone after a finite time period. The two entities leave the server through separate output paths simultaneously. Thus, the two outputs always have the same quantity. This server can represent OBJECT generation or message sending.

TABLE VI FOUR ’ILPES OF SERVERS AND 1)NORMAL server 1-apse of A < fi

PERFORhiANCE PARAMETERS

1-b)caSaofA~p

j

L’7fik-L

I

p= Alp 2)SPLIT SeNer 2-a)cBsBof A < p

3)MERGE server 3-a)case Of A A i A B