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
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.
2 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.
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.
In
program supervision different types of criteria are distinguished and their
representations crk may be
attached to supervision operators.
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).
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.
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 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).
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.
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.
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.
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.
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.
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.
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.
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
3 NAWAB, 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
6 THONNAT, 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
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
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.
|
|
