What can Program Supervision do for Program Reuse?
M. Thonnat and S. Moisan
I.N.R.I.A. - B.P. 93
F-06902 Sophia Antipolis Cedex, France
Abstract:
We are interested in knowledge-based techniques (called program
supervision) for managing the reuse of a modular set of programs. The
focus of this paper is to analyse which reuse problems program supervision
techniques can solve. First, we propose a general definition for program
supervision, a knowledge representation model, and a reasoning model. Then
we analyse program supervision solution for reuse in terms of the structure
of the programs to re-use and in terms of the effort for building a program
supervision knowledge base. The paper concludes with what program supervision
can do for program reuse from the points of view of the code developers,
the experts, and the end-users.
Keywords: Program supervision, software reuse, knowledge-based
system
1 Introduction
We are interested in knowledge-based techniques (called program
supervision) for managing the reuse of a modular set of programs. The
role of program supervision is to select programs in an existing library,
to run the programs for particular input data and eventually to control
the quality of their results. Various knowledge-based systems have been
developed for this purpose, notably in the domains of image processing
[1], [2] signal processing
3] and automatic control [4], [5]. For a more detailed
review see [6] which is a general review, [7] for software re-use in software
engineering and [8] for software re-use in signal processing and automatic
control.
The focus of this paper is to analyse which reuse problems
program supervision techniques can solve. This analysis is presented in
terms of the structure of the programs to be reused and in terms of the
effort for building a program supervision knowledge base. After this introduction,
section 2 explains our analysis of the re-use difficulties and proposes
a general definition of program supervision. Section 3 then presents a
knowledge representation model for program supervision, and introduces
the major notions of supervision operators and specialised criteria,
while section 4 presents how this knowledge is used during the reasoning
of a program supervision system. Section 5 details the conditions of use
of program supervision techniques in the framework of this model. This
paper concludes with what program supervision can do for program reuse
from the points of view of the code developers, the experts, and the end-users.
-
Reusing a Set of Programs
The use of existing libraries of programs has become a critical
resource in many disciplines. Numerous programs have been developed in
areas like signal or image processing and scientific computing. The programs
have been written by specialists in a particular area and are intended
to be applied by non-specialists in this area. Moreover new programs implement
more and more complex functions and their use is more and more tricky.
One drawback is that the non-specialist user must know how to choose programs
depending on different purposes, how to run each program, and how to chain
programs in the correct order to obtain a result. If it is too demanding
for an end-user to understand the complexity of new programs, they will
never be widely applied. When analysing the activity of re-using a number
of complex programs for an applied purpose, independently of the problem
of the application (i.e. the goal of the user and the semantics of the
data), it appears that a lot of problems come from the processing itself.
An end-user must make important efforts in order to have the data correctly
processed, and to efficiently use the set of programs.
For an end-user faced with a set of data to process and
a set of programs, applicable to the data, the first point is to understand
what each program does, i.e. to build a model of them. Afterwards,
since a single program is not usually sufficient to solve a complex processing
request, the end-user must figure out which programs can be combined together
and how. That means to know how to choose which program comes first, then
which ones may follow, and so on to eventually build "program combinations"
that achieve an application goal. Moreover, when multiple combinations
are possible some combinations are preferred (for example depending on
the adequacy of program features with respect to the data at hand). Then,
to execute a chosen combination, the user has to actually run the programs,
which implies knowing their precise calling syntax, together with their
usual parameter values, the type of input they accept, and the type of
output they produce (because the latter will become inputs for the following
programs in a combination). Internal data-flow managing between programs
may become very difficult to handle, e.g. if data are to be dispatched
among different programs. Finally, if, at any point of execution, the current
results are not satisfactory, the user must infer which previously executed
program is faulty, if it can be re-run with new parameter values and how
to compute the new values, or if it must be replaced by another program.
Every end-user could not have such a deep understanding
of the program semantics and syntax. One possible solution to this problem
is to use a tool that manages the processing complexity, in order to automate
the easy reuse of the programs. Among different techniques for reuse, we
propose program supervision techniques which aim at capturing the
knowledge of program use in order to free the user from the processing
details. The objective of program supervision is to facilitate the automation
of an existing processing activity, independently of any application. This
means to automate the planning and the control of execution of programs
(e.g. existing in a library) to accomplish a processing objective,
where each program computes one step of the processing. Using a program
supervision system, a user's input request produces as output the executions
of the appropriate programs with their resulting data as shown in figure
1.
More formally, we can define the program supervision process
as follows:
Given as input:
-
?={
pi/i ?1..n }
a set of programs pi, (existing executable codes);
-
{rpi ? rcj}
a set of representations rpi of the programs pi
and of their use, plus a (possibly empty) set of representations rcj
of known combinations cj of the programs;
-
{crk} a set of decision criteria;
-
I a set of input
data (real data, given by the end-user for a particular case);
-
eO
a set of expected output data (only
their type and number are known);
-
C(eO)
a set of constraints on expected output data;
it produces as output:
-
?={pk/"k
?1..m, m <=
n, pk ??
and $ partial order on pks
}, a plan i.e. a combination of programs (where the data flow is
correct and the same program may appear several times)
-
O
a set of actual output data such that:
-
O = ?
(I )
and
-
C(O)holds.
We propose to mimic the strategy of an expert in the use
of the programs by a knowledge-based system. A program supervision knowledge-based
system, according to this formal definition, helps a non-specialist user
apply the programs in different situations as shown in figure 2.
It is composed of a program supervision engine and a knowledge
base. The role of the program supervision engine is to use knowledge for
effective planning, execution and control of execution
of the programs. The knowledge base contains the representations rpi
and rcj of programs pi, combinations
of programs cj, and a set of decision criteria crk.
The contents of the representations rpi, rcj
and of the criteria crk should be sufficient for the
engine to select the programs, to initialise their parameters, to manage
non trivial data-flow, and to combine the programs to produce a satisfactory
plan ? depending on the
input data, constraints, and request.
3 Program Supervision Knowledge Base Model
In this section we present the main characteristics of a
program supervision knowledge base and we define the terms that will be
used in the model. Since the model presented here is intended to be independent
of any implementation, we have chosen general terms to name the common
concepts involved in program supervision. This terminology is the result
of an analysis of many existing program supervision systems that we have
either developed [1][9][10][11] or closely studied [12] [13][14][15][16][17][18].
Even if each system has its own vocabulary, some terms (like operators)
are widely used.
As program supervision is a general problem arising in
various application domains, we are interested in providing both knowledge
models and software tools which are independent of any particular application
and of any library of programs. A program supervision model defines ways
of describing programs for reuse, i.e. what structure reusable program
descriptions must have and what issues play a role in the composition of
a solution using the programs. It is thus a guideline that enables an expert
to represent programs to be reused and a guideline on how to reuse them.
A description therefore should not only describe a program but also the
information that is needed to apply it in different situations.
In addition to an abstract model of program supervision,
we have developed a knowledge description language (named YAKL)
to encode domain-specific information. YAKL is a model-theoretic
approach to knowledge modelling in program supervision and allows the knowledge
engineer to encode domain-specific program supervision knowledge bases.
YAKL descriptions can be checked for consistency, and eventually
translated into operational code. Some examples of the program supervision
concepts described below are given using the YAKL syntax.
Knowledge to perform program supervision may be categorised
into knowledge about the application domain, the programs of a particular
library -as well as the expertise domain (image processing for example)-
or the problem solving strategy. Most of this knowledge is modelled in
two major concepts, which are named supervision operators
and specialised criteria. The following sub-sections will define
those terms.
3.1 Supervision Operators
Supervision operators represent concrete programs (Primitive
operators) or abstract processing (Complex operators). They
mainly describe input and output
arguments (data or parameters) and pre- and post-conditions
that are tests which have to be checked before and after the execution
of the operator.. Both kinds of operators also encapsulate various criteria
crk (which may be represented by rule bases) in order
e.g., to manage their input parameter values (initialisation criteria),
to assess the correctness of their results (evaluation criteria on output
data), and to react in case of bad results (repair criteria).
Primitive operators Referring to the formal definition
of section 2, primitive operators are the rpi representations
of real programs pi. The execution of a primitive operator
corresponds to the execution of its associated program, provided that its
execution conditions (i.e. preconditions) are true. That is why
a primitive operator contains all the information needed for the effective
execution of the program.
Complex operators are the
rcj representations of higher level operations. They
don't have attached programs but they break down into more and more concrete
(complex or primitive) operators. They hence correspond to decompositions
that are usually predefined by the expert in the knowledge base. The allowed
types of decompositions are specialisation (or alternative), sequence,
parallel, and iteration. In all cases the sub-operators in a decomposition
may in turn be either primitives or complex ones. Since several operators
can concretely realise one abstract functionality the specialisation decomposition
type provides a way of grouping operators into semantic groups corresponding
to the common functionality they achieve. This is a natural way of expression
for many experts because it allows levels of abstraction above the level
of specific operators. In a sequential decomposition some sub-operators
may be optional. These decompositions -at different levels of abstraction-
must end with primitive operators.
Below is an example of a primitive operator o_th.
It performs a thresholding and has one input data (an image) and one numerical
parameter (the threshold). Only the structural part is shown, criteria
are detailed later. YAKL keywords are in bold face. Finally, the
concrete syntax will be instantiated with the actual values of the input/output
arguments for execution.
Primitive {
name : o_th
Functionality : thresholding
Argument descriptions
Input Data
Image name : in_image
comment : "original image"
Input Parameters
Float name : threshold
default : 1
Output Data
Image name : out_image
comment: "thresholded image"
I-O Relations:
out_image.path := in_image.path
}
3.2 Arguments
Arguments are attributes of supervision operators. There are three sorts
of arguments: input data, input parameters, and output data. Data arguments
have fixed values which are set for input data (e.g., an input image),
or computed for output data. The output data arguments can be "assessed"
during the reasoning by means of evaluation criteria. Parameter arguments
are tuneable, i.e. their values can be set by means of initialisation criteria
or modified by means of repair criteria.
3.3 Specialised Criteria
In program supervision different types of criteria are distinguished
and their representations crk may be attached to supervision
operators.
Common criteria
For each operator an expert may define three kinds of criteria.
Criteria provide a program supervision system with flexible reasoning facilities.
-
Initialisation criteria contain information on how
to initialise values of input arguments.
-
Evaluation criteria state the information on how to
assess the quality of the actual results of the selected operator after
its execution.
-
Repair criteria express strategies of repair after
a negative evaluation. A frequent repair strategy is simply to re-execute
the current operator with modified parameter values. In complex operators
they also express information transmission (e.g. the expert can express
that the bad evaluation information has to be transmitted to a sub-operator,
or to the father operator, or to any operator previously applied).
Criteria of complex operators
For a complex operator an expert may define other specific
criteria:
-
Choice criteria are attached to complex operators
with a specialisation decomposition type. They select the operators which
are the most pertinent among all the available sub-operators, according
to the data descriptions and the characteristics of the operators. This
kind of criteria is used for planning purposes.
Here is an example of a choice rule in YAKL language:
Choice criteria
Rule name : r-choice
comment : "choose operator constr-with-filter if image is noisy"
Let c a Context
If
c.noise == present,
size-filter > 0
Then
use-operator constr-with-filter
;
-
Optionality criteria are attached to complex operators
with a sequential decomposition type. They decide if an optional sub-operator
has to be applied depending on the dynamic state of the current data.
Such criteria increase the flexibility of the system.
3.4 Knowledge Base Concepts: Summary
Figure 3 summarises the main concepts of a program supervision
knowledge base that have been presented in the previous sub-section and
their relationships. It shows an abstract view of the concepts and their
relations in the form of an UML (Unified Modelling Language [19])
class diagram. Most of the relations are ‘one to many’, e.g., one
supervision operator is connected to many input data (in UML notation,
* denotes 0 or more) and to 0 up to 3 common criteria (as presented in
section 3.3): since no kind of criteria is compulsory, an operator may
have no criteria at all. In the same way, a complex operator is connected
by a composition relation (denoted by a diamond) to several (at least one)
sub-operators. Not all the types of complex operators with respect to the
type of their decomposition are represented in this simplified view (only
sequence and specialisation types are because they are the most commonly
used).
4. Program Supervision Reasoning
In this section we briefly present how we model the reasoning
process for program supervision into several phases. A program supervision
task is solved by a problem-solving method adapted to experts' reasoning
processes and domain requirements.
4.1 Reasoning Phases
The reasoning of program supervision is implemented in the
supervision engine. The role of the engine is to exploit knowledge
about programs in order to produce a plan of programs that achieves the
user's goal. It mimics the strategy of an expert in the use of programs.
The final plan that produces satisfactory outputs is usually not straightforward,
it often results from trial and error. The reasoning engine explores the
different possibilities and computes the best one, with respect to expert
criteria, available in the knowledge base.
The engine roughly automates a cycle of four reasoning
phases to solve user problems (see figure 4), that can be completely or
only partly automated.
-
The planning phase can use a hierarchical strategy
or a mechanism based on preconditions and effects of available programs
on data description.
-
The execution phase runs (directly or via a communication
protocol) the programs with current data and adequate parameter values.
-
The evaluation of the returned results can sometimes
be fully automated thanks to measurement computation, expert-defined criteria,
methods to compare results with reference cases, etc.
-
Finally, the repair phase offers smart backtrack
possibilities to different return points, depending on the type of decisions
that can be reconsidered.
According to the type of reasoning process to carry out,
there may exist variants of the four phases of this general model, that
can also be more or less interleaved. For instance the planning phase may
be based on a Hierarchical Task Network (HTN) or may use Partial Order
Planning (POP).
4.2 Role of Criteria
During the reasoning phases, the engine not only exploits
the operator descriptions, but also exploits criteria crk
that are described in the knowledge base. The specialised criteria play
different roles and they are involved in different phases of the program
supervision reasoning. For example, choice criteria between supervision
operators are related to the planning phase, while initialisation
criteria are related to the execution phase. The greater the knowledge
base is in terms of criteria, the more flexible the related reasoning phase
will be.
For example, let us see how the criteria take place in the specific reasoning phases of a particular program supervision engine, named Pegase. Figure 5 details the four phases of Pegase engine reasoning and the control between them. It shows where the criteria are used by the engine.
5 Reusing a Set of Programs with Program Supervision
Program supervision aims at large scale software management
and utilisation. The main phases of planning, execution, evaluation, and
repair are generic tasks of program supervision, software reuse and software
engineering methodology. Specific to program supervision is the knowledge-based
approach. Different categories of knowledge must be elicited in order to
adequately build a program supervision system.
5.1 Requirements for Using Program Supervision techniques
In this section we analyse which properties the programs
pi and their arguments must verify in order to be candidates
for re-use with program supervision techniques. In addition, we propose
general advice about the construction of operators (rpi
and rcj) and criteria (crk).
Program properties
If there is one unique and clearly defined functionality
for each program pi the model is directly applicable.
A primitive operator rpi is thus created for each pi.
If it is not the case, that is if one program achieves several distinct
functionalities, the solution is either to rewrite the program in order
to split it into smallest ones, one per functionality, or to define as
many knowledge base operators rpi as there exist sub-functionalities
in the program. We can note that, as a side-effect, the building of a program
supervision knowledge base may have an influence on the methodology of
code design, resulting in more modular and structured codes. This of course
implies an additional effort at first, but in the long term it is an advantage
both for code maintenance and for knowledge base evolution.
Moreover, if the programs are already managed by an ``interpreter''
such as a command language or a graphical interface, additional work is
necessary to solve the communication problems between a program supervision
system and the individual programs.
Argument properties
Programs can only be re-used if they do not work with ``magic
numbers'' (i.e. fixed values for important internal parameters that
have been obtained by past experiments). So, program supervision implies
explicit internal parameters for each program by rewriting and adding explicit
arguments. The same problem may arise with data which may be implicit (e.
g., in the case of programs communicating via a shared memory). There
are two possible solutions: the first one is to rewrite the program pi
and to create new arguments for all data. A second solution is to keep
the use of a shared memory, for efficiency reasons, but to represent explicitly
the implicit arguments in the primitive operator rpi
corresponding to pi. When parameters exist, the operator
rpi must contain the knowledge on how to tune them. This
is relatively easy for initialisation criteria, but is more demanding for
repair criteria expressing how to adjust their values with respect to bad
result evaluations.
Complex operator properties
Introducing a first abstraction level is natural when there
exist several alternative primitive operators sharing the same functionality.
The solution is to create in the knowledge base one complex operator per
functionality. The type of decomposition of this complex operator is of
specialisation type and the sub-operators are the alternative primitive
operators. When typical program combinations cj are available
(e.g., shell scripts, with sequences, alternatives, etc.) this information
can be directly described and represented in the knowledge base by creating
one complex operator (rcj) per typical combination cj.
For instance if the combination cj is a sequence of programs,
the type of decomposition of the complex operator is a sequence and the
sub-operators are the ordered list of the primitive operators rpi
representing the programs pi in the sequence cj.
The knowledge base can contain several abstraction levels when the body
of a complex operator is itself composed of other complex operators. It
is thus possible to represent taxonomies of functionalities with complex
operators. If for one single functionality, there exist several operators
achieving it, the existence of these alternatives leads to a richer and
more flexible knowledge base, with a wider range of applicability.
Criteria properties
First, the criteria are specialised: if there are known criteria
in the choice of sub-operators, input parameters initialisation, output
data evaluation, or repair strategies, even if these criteria are only
available for specific applications, they can easily be expressed in the
knowledge base using the adequate criteria type provided by the model.
However, the criteria are not mandatory: each operator must not contain
all types of criteria. The repair knowledge for instance can be located
only in a few precise operators. Even if the knowledge representation of
the operators is homogeneous, their usage is very dependent on the knowledge
to be expressed.
Finally, the criteria can manage the degree of interactivity
with the user. If there exist methods for automating the computing of values
(parameter initialisation methods, parameters adjustment methods, or methods
for the evaluation of the results), these methods can be directly translated
into specialised criteria. If these methods do not exist, specialised criteria
can nevertheless be created to guide the interaction with the end-user.
It is especially useful for the evaluation of the results: the role of
the criteria can be limited to the automatic display of some output data
and of a list of possible assessments which are compatible with the repair
knowledge. The user only selects a particular assessment for the displayed
results.
Summary
It appears that the knowledge modelling effort depends on
the set of programs to be supervised. This fact leads to a coarse methodology
of knowledge base building: the easiest way is to begin by describing concrete
individual programs, then to create higher levels of abstraction using
complex operators. Criteria may be added afterwards, the more criteria
the knowledge base contains the more efficient and flexible the program
supervision process will be.
5.2 Program Supervision Knowledge Bases
This section uses three different examples to show how program
properties have influenced the knowledge base building. We have developed
two program supervision engines compatible with the knowledge representation
model presented in section 3. For more details on these engines see [1][9]
for the Ocapi engine and see [11] for the new Pegase one. These engines
have been used for building several knowledge bases.
Progal
The first example is an application in astronomy, where the
role of the program supervision system is to automate a complete processing
chain in order to cope with possible variations in the input data (images
of galaxies) [20][21]. There was already a modular set of 37 image processing
programs. Only one program has been split into two programs pi,
to allow an easier use of the repair knowledge. Thus, in the Progal knowledge
base 38 primitive operators rpi have been created. Progal is a rich
knowledge base with 54 complex operators rcj and a lot
of abstraction levels. The criteria crk are numerous
and fully automatic: there are 20 choices between operators, 16 parameter
initialisations, 11 result evaluations, 21 repair criteria. Thanks to all
those criteria, the complete image processing for morphological galaxy
description is fully automated and provides inputs directly for an automatic
galaxy classification system. A first version of the knowledge base has
been developed with the Ocapi engine, the current knowledge base works
with the Pegase engine.
Promethee
The second example is a stereo-vision-based module performing
some technical functionalities, such as 3D computing and obstacle detection.
This module is difficult to use due to the existence of many technical
parameters needing tuning. The Promethee knowledge base [22] contains 24
primitive operators corresponding to the 24 programs and only 15 complex
operators. Among the 120 criteria there are only 15 choice criteria. Some
of the 20 evaluation criteria are interactive ones, because of the generality
of this module which can be applied on very different images corresponding
to various application domains. On the other hand, the technical knowledge
on how to initialise and adjust the parameters is important thanks to 64
initialisation criteria and 21 repair criteria. This knowledge base works
with the Ocapi engine.
FAMIS
The third example falls within the domain of medical imaging.
The objective is to offer clinicians a wider access to evolving medical
image processing techniques and more precisely with Factor Analysis of
Medical Image Sequences (FAMIS [23]). In this case, there is no need for
complete automation. There are eight big programs performing several functionalities,
plus 7 secondary programs. So, the knowledge base [24] contains more primitive
operators (22 rpi) than there exist actual programs (15).
There are 11 complex operators with alternative or sequential arrangement
decompositions. The criteria are numerous in the current knowledge base
: 120 criteria among which 10 choice criteria, 3 optionality criteria,
30 parameter initialisations, 30 results evaluations, 50 repair criteria.
Most of the evaluations criteria and some of the choice and optionality
criteria work in interaction with the clinician end-user. This knowledge
base works with the Pegase engine.
6 Conclusions
We can summarise what program supervision can do for program
re-use from the points of view of the code developers, the experts and
the end-users. Obviously, code developers can not expect any improvement
in the quality, complexity or speed of the individual programs only by
application of program supervision techniques. A first major impact of
program supervision for code developers is that the building of a program
supervision knowledge base may influence the methodology of code design,
leading to more modular and structured codes. In spite of this additional
coding effort, it contributes in the long term to better code maintenance
and knowledge base evolutions. In fact the program supervision approach
provides the resulting system with extensibility, as it is easier to add
new programs to the library. The second major impact for code developers
concerns the diffusion of their code. The knowledge encapsulation of the
codes using program supervision techniques allows a wider usage of the
codes because the program supervision system can adapt its behaviour dynamically
to the end-user data.
For the expert we propose a model which provides a framework
and a clear description of the structure of the knowledge involved in program
supervision. Yet, even if all the requirements on programs previously mentioned
in section 5.1 are met, the building of a knowledge base for program supervision
is still a big effort for the expert. A partial help can be provided by
verification techniques as outlined in [25]. However, once the program
supervision knowledge base has been written following the advice developed
in section 5.1, the managing of the set of programs is completely handled
by the program supervision engine. No more effort is necessary for the
expert, because the knowledge modelling is completed. This knowledge capitalisation
is an important result per se; it allows a company to compensate for the
lack of code developers or experts.
For an end-user, program supervision techniques facilitate
the re-use of a set of programs. The end-user has only to provide a request
with input data, possibly some constraints on output data and some intermediate
result evaluations. The program supervision approach provides the resulting
system with more or less autonomy, since the user is not burdened with
technical processing problems. In certain cases completely autonomous systems
can even be developed.
References
1 CLEMENT, V., and THONNAT, M.:
‘Integration of Image Processing procedures, Ocapi: a Knowledge-Based Approach’.
Computer Vision Graphics and Image Processing: Image Understanding),
March 1993, 57(2) 2 BRITISH-AEROSPACE : ‘VIDIMUS Esprit Project
Annual Report’. Technical report, Sowerby Research Centre, Bristol, England,
1991 3NAWAB, S.H. and LESSER, V.: ‘Integrated Processing and Understanding
of Signals’. A.V.Oppenheim and S.H.Nawab, editors, Symbolic and Knowledge-Based
Signal Processing, 1992, pp. 251-285. Prentice Hall,. 4 HAEST,
M., BASTIN, G., GEVERS, M., and WERTZ, V.: ‘ESPION: An Expert System for
System Identification’ Automatica, 1991, 26(1) pp. 85-95
5 LARSSON, J.E. and PERSSON, P.: ‘An Expert System Interface for
an Identification Program’. Automatica, 1991, 27(6) pp. 919-930
6THONNAT, M. and MOISAN, S.: ‘Knowledge-based systems for program
supervision’. First international workshop on Knowledge-Based systems
for the (re)Use of Programs libraries KBUP'95, 1995, Sophia Antipolis,
France, INRIA, pp. 4-8 7van den ELST, J., van HARMELEN, F., and
THONNAT, M.: ‘Modelling Software Components for Reuse’. Seventh International
Conference on Software Engineering and Knowledge Engineering,, June
1995, Rockville, Maryland, USA, pp. 350-357 8 SHEKHAR, C., MOISAN,
S., and THONNAT, M.: ‘Towards an Intelligent Problem-Solving Environment
for Signal Processing’, Mathematics and Computers in Simulation,
March 1994, 36 pp. 347-359 9 THONNAT,M., CLEMENT, V. and
van den ELST, J.: 'Supervision of Perception Tasks for Autonomous Systems:
the OCAPI approach', Journal of Information Science and Technology,
1994, 3(2) pp. 140-163 10 van den ELST, J., van HARMELEN,
F., SCHREIBER,G., and THONNAT, M.: ‘A functional specification of reusing
software components’. Sixth International Conference on Software Engineering
and Knowledge Engineering,, June 1994, Tallin, Estony, pp. 374-381
11 VINCENT, R.: ‘Etude des mécanismes de gestion des erreurs
dans les systèmes a base de connaissances de pilotage de programmes’.
PhD Dissertation, Univ. Nice (France), 1997 12 GONG,L. and KULIKOWSKI,C.:
'Composition of Image Analysis Processes through Object-Centered Hierarchical
Planning'. IEEE Transactions on Pattern Recognition and Machine Intelligence
(PAMI), 1995, 17(10) pp. 997-1009. 13 CHIEN, S. A. and MORTENSEN,
H. B.: 'Automating Image Processing for Scientific Data Analysis of a Large
Image Database'. IEEE Transactions on Pattern Analysis and Machine Intelligence,
1996, 18(8) pp. 854-859 14 LIEDTKE, C.-E., MUNKEL, H. and
ROST, U.: 'SOLUTION for a learning configuration system for image processing'.
Lecture Notes in Artificial Intelligence 1415, 1998, pp. 437-447 15
DALLE, P. and DEJEAN, Ph.: 'Planification en traitement d'images : approche
basée sur les données'. RFIA'98, Jan 1998, Clermont-Ferrand,
France, pp. II-75-84 16 CLOUARD, R., ELMOATAZ, A., PORQUET, C. and
REVENU, M.: 'BORG: A knowledge-based system for automatic generation of
image processing programs', IEEE Transactions on Pattern Analysis and
Machine Intelligence, 1999, 21(2) pp. 128-144 17 WILLAMOWSKI,
J., CHEVENET, F. and JEAN-MARIE, F.: 'A development shell for co-operative
problem-solving environments' Mathematics and computers in simulation,
1994, 36(4-6) pp. 361-37 18 PARMENTIER, T. and ZIEBELIN,
D.: 'Distributed problem solving environment dedicated to DNA sequence
annotation' Lecture Notes in Artificial Intelligence 1621, 1999, pp. 243-258
19 UML, version 1, Rationale Rose Software Corporation, Santa Clara,
US, 1997 20 THONNAT, M., CLEMENT, V., and OSSOLA, J-C.: ‘Automatic
galaxy classification’. Astrophysical Letters and Communication,
1995, 31(1-6) pp. 65-72 21 VINCENT, R., THONNAT, M., and
OSSOLA, J-C.: ‘Program supervision for automatic galaxy classification’.
International Conference on Imaging Science, Systems,
and Technology CISST'97, June 1997, Las Vegas, USA,
pp. 34-43 22THONNAT, M., CLEMENT, V., and van den ELST, J.: ‘Supervision
of perception tasks for autonomous systems: the OCAPI approach’. Journal
of Information Science and Technology, Jan. 1994, 3(2) pp. 140-163
23FROUIN, F. , BAZIN, J.P., Di PAOLA, M., JOLIVET, O., and Di PAOLA,
R.: ‘FAMIS: A Software Package for Functional Feature Extraction from Biomedical
Multidimensional Images’. Computerized Medical Imaging and Graphics,
1992, 16(2) pp. 81-91 24CRUBEZY, M., AUBRY, F., MOISAN, S.,
CHAMEROY, V., THONNAT, M., and Di PAOLA, R.: ‘Managing Complex Processing
of Medical Image Sequences by Program Supervision Techniques’. SPIE
International Symposium on Medical Imaging'97, February 1997, NewPort
Beach, California, USA, SPIE’97:.3035-85 pp. 614-625 25 MARCOS,
M., MOISAN, S., and del POBIL, A. P:. ‘A Model-Based Approach to the Verification
of Program Supervision Systems’. 4th European Symposium on the Validation
and Verification of Knowledge Based Systems, June 1997, Leuven, Belgium,
pp. 231-241
Figure 1: A program supervision system helps a
user to re-use a set of programs for solving a request on input data I
to obtain output data O.
Figure 2: A knowledge-based program supervision
system helps a user to reuse a set of programs for solving a request on
input data I to obtain output
data O, as the results of the
execution of a plan ?. It
is composed of a program supervision engine and a knowledge base. The knowledge
base contains the rpi and rcj representations
of programs pi and combinations of programs cj,
as well as the representations of various decision criteria crk
Figure 3: Summary of the main concepts of a program
supervision knowledge base and of their relationships.
Figure 4: A user request is solved
by different reasoning phases: (1) the planning
of (part of) the solution, that selects and organises programs into a sequence
of actions, (2) the monitored execution of
each action after appropriate refinement and parameter tuning, (3) the
evaluation of the results and finally (4)
the repair of the (partial) solution if results
are not satisfying. Bold arrows show the main recursive loop. Repair is
performed either by simple re-execution of the same operator or by re-planning.
Figure 5: An example of the use of criteria in the reasoning
of a particular program supervision engine, Pegase.
-
