SeisView provides a basic framework to construct an exploration and production integrated workstation. The programmer or the explorationist constructs new applications or new processing sequences by taking preprogrammed functional objects and graphically connecting them to form a new application program without writing any new code in a traditional high-level language. These objects are interactive objects (menus, icons, etc.), data objects (plane, trace, etc.), processing program objects (NMO, Mute, etc.).
For the programmer this system provides an object-oriented environment to describe (1) the rules of the dialogue between the system and the user, (2) the rules to access the programs, (3) the relations between the different programs.
For the explorationist this system will provide an homogeneous, integrated, easy-to-use workstation. SeisView includes a planner which advises the user what to do next, and how to use some processing tools, then guides the user in building the processing tasks. The planner controls the processing history.
In the past, exploration and production processes have been done mainly in a batch environment on a main-frame. These processes are not very communicative and the interaction between the explorationist and these processes is very limited. The selection of the “best” parameters for each of these programs requires an experienced user. Problems arise when a user has to deal with a task but lacks details about appropriate tools for the task. Because a typical processing task is composed of a chain of such processing programs the task of processing seismic reflection data becomes a complex procedure (Bashore et al., 1989).
Today the integration of the exploration process in a unique desktop workstation is one of the hottest topics in exploration and production. Such enthusiasm is explained by many facts. First, pictures are worth thousands of words and workstations bring “pictures” to the desk. Second, interactive processing is more easily learned and is a more attractive process where the explorationist gets immediate answers to his manipulations. Third, integrating every exploration and production application onto the same screen may facilitate the communication between geophysical, geological, and reservoir engineering applications.
Unfortunately building graphic interfaces is intrinsically difficult. Industrywide research has shown that user interface development costs continue to increase. In graphically oriented applications 80 percent of the coding time and cost is spent on the user interface. Clearly tools which enhance efficiency in developing user interfaces can provide dramatic cost savings. The same research has shown that a rapid prototyping can cut development cost by 40 percent. The main problem in building graphic interfaces is that, for the first time, end user and programmer have a very tight relationship. This tight relationship enhances all the problems of human-to-computer communication. Another major problem is that workstation technology is changing very rapidly and is becoming increasingly difficult to learn. Finally, integration of all exploration and production applications means standardizing these applications under the same scheme. An intercommunication standard needs to be defined.
An interactive system should provide the user with sophisticated task distribution, consistency across applications, standardization of the processing, and organizational environment. Such an environment should benefit the developer/maintainer, the domain specialist, and the end user. The system would provide a complete active environment for the developer or the maintainer and must allow the expert to encode and use domain knowledge to give a direct expression and interaction in the natural terms of the domain. Finally, the system must provide easy to use interfaces for end users. Such a system must afford the explorationist and the programmer a common base for expressing their ideas.
Given the nature of the described task, i.e., building a user and programmer friendly graphic user interface system, the SeisView knowledge-based system was built. SeisView provides an interactive front end to seismic processing. SeisView encodes knowledge about the programs, the data, and the interactive objects. According to Smith et al. (1989) three major problems exist in building such a knowledge based system: (1) cost of knowledge acquisition, (2) management of the complexity, and (3) cost of end-user interface construction. To overcome these problems SeisView uses an object-oriented intelligence data base which describes simple knowledge-object or frame. The objects are program modules, data, data base query objects, math library, and graphic interface objects. The programmer or the explorationist constructs new applications or new processing sequences by taking these preprogrammed functional objects and graphically connecting them to form new application programs without writing any new code in a traditional high-level language.
A discussion of user interface models and the object-oriented model will be followed by sections presenting the implementation of different components of a user interface.
An input/output model that describes how the user input and system output are presented on a screen.
A dialogue model that describes the rules of dialogue between the system and the user. Two aspects of the dialogue interface can be identified:
(a) the way a user is guided by the system to enter commands, e.g., with menu selection or system prompts.
(b) the rules of the dialogue interface defining the amount of control the user has over the interface, i.e., how to start and stop a task or how to get on-line help.
A tool interface model that describes the rules which define access to underlying system tools. Possible improvement of the tool interface can be achieved by providing:
(a) Knowledge about the task domain: strategies, methods, experience available, warning and suggestions for certain situations.
(b) Knowledge about the objects which may be applied in a solution: information about the objects, the tools, and the task.
(c) Knowledge about the components of the task: tools, objects, subtasks.
An organizational interface model that attempts to describe relations between different tasks executed by different users.
According to Hendler and Lewis (1987), interface design is more complicated than just putting up windows on the screen. One technology proposed for helping designers cope with ever-increasing demands on their system is User Interface Management Systems (UIMS). The UIMS method advocates creating tools which allow the designer to define the interface in a declarative way, usually by use of some special language features. This form of interaction allows the designer easy experimentation with different forms of the interface.
Many systems have already implemented these ideas. Perhaps the best-known system, HyperCard (Goodman, 1987), is used to design applications on the Macintosh. In HyperCard, the card or window is drawn using a special editor. The card is then inserted in a stack which represents the way the user goes through the application. The card and its elements are saved in a description file. Operations described in a script can be associated with interactive objects.
The same idea is used to build SeisView. SeisView provides a graphic environment for building interfaces to typical processing programs and for building complex seismic processing tasks (Figure 2).
The intuitive appeal of object-oriented programming is that better concepts and tools are provided to represent the natural structure of the real world as close as possible. The advantages of direct representation capability in programming and data modeling are (1) data abstraction and encapsulation, one-to-one correspondence between program objects and the problem objects (Figure 3), and (2) reusable tool kits with well-defined minimal interfaces. Objects are abstract data types which have “an existence of their own” and can in some sense communicate with each other. From the point of view of either object-oriented design or programming, an object is some private data together with the operations on that data. Object-oriented programming addresses language, implementation, and programming environment issues. To arrive at an object-oriented solution to a problem, what the objects should be must be defined. In an object-oriented design each of the major modules corresponds to an entity either in the user’s world or in an implementation of a solution to the user’s problem. In seismic processing the program main entities are the data. Many types of data may be needed, e.g., Plane, Trace, and Cube. Seismic operations are frequently represented in data-flow diagrams. Each fragment consists of one process together with the input data, output data, and control parameters. Frequently, control parameters can be considered as an object. For example the dimension of the data set is an object containing axes definition. Furthermore the splitting between the object handling data manipulations and the object-handling data coordinates simplifies the interfaces to the operation of the objects. Some of the data flows may also become candidate objects. For example, reading or writing the data and the files may be the role of input and output objects.
Inheritance is a powerful way of retrieving information (Parsave et al., 1989). Inheritance allows the system to retrieve or change information that is shared among different members of a category or class of objects within a hierarchy. Inheritance is based on the notion that objects or concepts tend to form groups and that members within a group tend to share common properties (Figure 3). Inheritance in knowledge representation allows for the sharing of information among a set of elements with uniform structure. Objects are organized in a hierarchy or network, with each element at a lower level inheriting the properties of the elements at a higher level. By using inheritance our knowledge can be organized in a way that allows the inference of information that is not directly available.
SeisView, a UIMS, supports the development and execution of a user interface of a software system. SeisView supports incremental development of the user interface from the prototyping phase through production to maintenance or sustaining engineering.
A main goal of SeisView is to encourage the separation of a software system into an application portion and a user-interface portion in order to provide the application developer with a presentation-independent interface. The application portion consists of those components of a software system that implement the “core” application functionalities of a system. The application portion may be represented by a batch program. The user-interface portion consists of those components that implement an end-user dialogue. A dialogue is the specification of the presentation of application information and end-user interactions. During the design stage, the system designer decides which functions belong in the application component and which belong in the user interface.
SeisView is implemented using a standard UIMS architecture which consists of three major layers: (1) the presentation layer, (2) the dialogue layer, and (3) the application layer. The three different layers of the standard architecture are viewed as providing differing levels of end-user feedbacks (Figure 4).
One way of viewing the three levels of the architecture is the level of functionality provided for user input. The presentation layer is responsible for lexical functionality, the dialogue layer for syntactic functionality, and the application layer for semantic functionality. In terms of a menu example, the presentation layer has responsibility for determining which menu item was selected. The dialogue layer has responsibility for deciding if the choice requires application action. The application layer is responsible for implementing the command implied by the menu selection.
The end-user interface for a software system is specified formally as a dialogue. The dialogue is executed by a dialogue manager at run-time in order to provide an end-user interface for a software system. The dialogue specifies both the presentation of application information and end-user interactions. The object-oriented SeisView dialogue specification language (SVUIL) allows dialogues to be arbitrary complex. The SVUIL includes both the presentation layer and the dialogue layer. The end-user interface described in the user-interface descriptive file with the SVUIL is compiled by the dialogue manager. The knowledge of the SVUIL is not required to build user interfaces. An interactive interface builder helps construct interactively any dialogues.
The application portion provides the functional portion of the software system in a presentation-independent manner. The functional portion may be developed in C+ +, C, or Fortran. SeisView provides an object-oriented model for building application which manipulates graphic editors. SeisView also provides a Computer Assisted Environment (CASE) for writing seismic applications. From the description of the application interface to the processing environment, an auto-writer generates the processing interface application code and stores, into a processing knowledge data base, information used by the parameter manager, the dialogue manager, the planner, and the tool editor.
SeisView is constructed on top of the X-Window system (Scheifler and Gettys, 1986). SeisView is written in C+ + (Stroustrup, 1986), an object-oriented language. SeisView used a C++ tool kit written on top of the X-Window library called InterViews (Linton and Calder, 1987). InterViews provides the basic user interface package (buttons, menus, object-oriented graphic, and object-oriented text).
The dialogue model describes the rules of dialogue between the application and the user. Processing programs are managed by a set of parameters. The first step in making seismic processing more interactive is to build for each processing program an interactive interface. This interface will be composed of control panels. The control panel provides the user a simple way to enter parameters. The parameters are displayed with familiar and intuitive controls (slider, button, etc.) in whatever order is preferable.
SeisView provides the components to define and manage the control panels of a tool’s graphic interface (Figure 5). Each tool is represented by a set of interconnected windows where the user enters data. These control panels are described in a description file using SVUIL. The interface is completely separated from the program, so no reprogramming of the tool needs be done to create a specific interface for this program. Changes to the interface are quick and easy and accomplished merely by editing the description file. No recompilation is required. SeisView also provides the means to write and design any graphic user interface (Figure 6). SeisView combines an application code and a user-interface description to produce a complete application. The separation of interactive behavior and output aspect, as well as the separation of the interactive behavior and the abstract behavior (suiting a particular application), is enhanced by SeisView and simplifies code development and code maintenance.
The next section describes the components of the dialogue model, the user interface objects, and then the communications procedures between the different interactive objects.
Interactive objects are divided into two parts: (1) simple interactors and (2) composite interactors or scenes. The different interactors are derived from InterViews interactors. All interactors maintain an output state and an input value. Also, all interactors implement a set of operations defined in the generic interactor class. These include operations for
reading the interactor attached description;
setting the interactor output state;
setting, checking, and retrieving the interactor values;
and popping up the interactor and letting the dialogue proceed.
Each interactive object has a set of characteristics or attributes. A user can customize an interactor by assigning values to the interactors attributes. Standard attributes are, for example, a help attribute and a font attribute. A help for an interactor is a short sentence describing the object and its purpose (e.g. “apropos” command). For a complex object the help object may be equivalent to manual pages (Figure 7). All interactors have an initial value that can be a constant or an expression evaluated at run-time. Sophisticated composite objects such as Box and Card eliminate the need to specify x, y coordinates. Figure 8 presents an example of a descriptive file, the interactive panel generated from interpretation of the file description, and an example session with the SeisView Interface Builder to edit the panel.
An application program must be able to implement the user’s request. In many tool kits this flow of run-time information from the interface to the application is accomplished through the call-back mechanism. The script is an extension of the call-back concept. The script is a little piece of program inside the descriptive file. The script sets user variables from interactive object attributes and may call user application functions. But the script may set interactive object attributes and call tool-kit functions, and may change, at run time, the look of the interface by changing the value of some objects attributes, or by creating or destroying interactive objects. The main advantage of the script is to have, in the same file, the object description and its function.
A script is written in a C-like syntax. All classic C instructions, types, and expressions are available, and some new language features have been added to control the interface objects:
This notation, similar to the one used in the UNIX shell scripts, avoids polluting the application call backs with tool kit dependent calls. Furthermore an
application function can be directly called with the right arguments and not with some tool kit special arguments.
Each interactor has at least three scripts. Each script is executed at a certain time of the life of the interactor. A script initializes the interactor, another script handles certain operations during the manipulation of the interactor, and finally the third script performs some operations at the end of the manipulation, typically testing the value input by the user.
The navigation rules associated with an object allow the programmer to link scenes to one another dynamically. A navigation rule is equivalent to a conditional go to. Navigation rules avoid the need to hide the navigation control in a call back function. A navigation rule has the following syntax:
where ifCond can be an empty condition, a condition associated with an event type, or a script returning true or false. thenScenes is a list of windows to be displayed to the user, or either one of the following keywords: Next, Prev, and Exit.
Next: signifies to the dialogue manager to validate and unmap the current window (A validation saves input values, activates validation scripts, etc.).
Prev: indicates the dialogue manager to return to the previous window without validation.
Exit: forces the dialogue manager to terminate.
Navigation rules allow the application developer to link the different scenes in a dialogue chain. These rules may be used by the User Interface Manager to help the user by drawing automatic flow charts (Figure 9), to transform a serial interface into a parallel interface, to make the application appear history or context dependent. Navigation rules and scripts present easy ways to achieve the dialogue model.
Standard classes of application objects, interactive objects, and data objects are available. In addition new classes of objects can be added. Each object is a particular instance of a class and the class must be defined. A class is characterized by its data or attributes and by its methods. An attribute may have many types such as int, float, and string. The attribute type may also be a user type like Button. Attributes may be predefined in the class declaration. In the following example, the basic Interactor class and the Button class are described:
The description of the user classes permits the implementation of a modular interface builder which will understand all interactive objects and which will allow the programmer complex browsing facilities to help find the attributes available to describe or modify an object.
Context dependency may be made explicitly using dependency relations. Each attribute of an object (graphic, interactor, application) may be dependent on a set of other objects attributes. Whenever an attribute is updated the dependent attributes are also updated. Scripts are associated with attributes to compute new values in response to changes in the attributes. The dependency relation specifies what attributes are related, whereas these methods specify how they are related. The dependencies and their associated methods are specified as follows. In the next example an input text interactor ‘aField’ is disabled if a button ‘aButton’ is selected.
Another example of an important attribute dependency is the dependency which links the undo menu text item and the current command.
Similarly in the NeXT system (Crandall and Colgrove, 1989) objects can be connected in order to describe their dependency relation. There are two types of connection: if-needed connection and if-changed connection. An if-needed connection describes the objects which are going to be set when an object needs to be set. An if-changed connection describes the objects which are going to change when an object changes.
An object-oriented implementation makes possible the implementation of basic editing functionalities such as Move, Scale, Rotate, and Reshape in a generic way. All the graphic objects MultiLine, Polygon, BSPline are encapsulated in a generic graphic object to give to the programmer a unique representation of all the common functionalities of these objects. Then a generic editing function can be built, with the graphic object giving itself all the information needed by the editing function. For example a Reshape editing function will ask the graphic object which kind of graphic feedback should be given to the user when the user is performing an interactive operation on this object.
A library of generic editing options has been constructed and may be used to build many editors. The significance of a particular manipulation must still be implemented but the look and feel of the manipulation need not be reimplemented maintaining a consistency across editors (Figure 10). SeisView generic editor provides these capabilities. For example the two editors Overlay (Claerbout, 1987) and Zplane (Claerbout, 1988) rewritten using SeisView have a common look and common functionalities.
Communication.—A manipulation links two objects: the Editor and the object being edited or Editee. We need to describe Editee and Editor objects to be able to establish a link between the application and the interface. An Editor object has attributes of type look and feel, but more importantly, has attributes describing the meaning of the editor object for the application. An Editee object
100 has characteristics describing which Editor object is going to edit the Editee. The dialogue between the application and the interface will be described in two steps: program description and interface description. An example of the protocol of communication follows: a routine layerCreationEnd is called after the creation of a layer. This Fortran subroutine inquires the list of coordinates of the digitized layer x,y, the layer identification number layerldent and returns a flag to the digitalization tool. The pseudo-code of the subroutine follows:
The digitizer object or DigitizeTool is described as follows in the interface description file:
where fieldLayerldent is an interactor in which the user has defined the layer identification number. Its value is set to the layer identifier and the routine is called.
Editee description.—The Editee must be defined in the descriptive file. An Editee description defines which action can be done on this object. For example, if we want the Layer object to have the following editing characteristics:
standard “with confirmation asked before destruction” destructor,
no scaling authorized,
special creating and moving tool
Manipulation Model and History.—A manipulation is managed by an Editor using the following scheme:
(1) Editor → Editee ← Manipulator Rubberband
(2) Editor → Editee ← Command
(3) Editor → History → Command → Editee
(1) An Editor object asks the Editee how to manipulate the Editee graphic. The Editee first creates an object called a Manipulator which manages the user actions in implementing a style of manipulation such as down-click-drag-upclick style manipulation. The object manipulated by the Manipulator is typically a Rubberband representing the Editee graphic.
(2) Then the Editor asks the Editee to create a Command object from the result of the user’s actions.
(3) Third, the Command is stored into a History object which implements a queue of Commands. Finally, the History executes the Command. The Command will then ask the Editee to interpret its characteristics. A Command knows how to redo or undo itself by letting the Editee interpret the right kind of parameters. For example a Move Command will store the user defined displacements (dx, dy) and let the graphic interpret either the “do” displacement (dx, dy) or the “undo” displacement (–dx, –dy).
Each Command has a name and knows how to read and write its attributes from and to a command line or a file. Using the class Command with the class Editee and the class Manipulator, SeisView generic editor provides an object-oriented scheme to edit any graphic and to store editing history.
A tool is a processing program with inputs, outputs, and an interactive interface. To be able to build a tool editor like the one presented in Figure 1, a tool must contain information such as its input and output streams, its parameters, and its type or class. As in Bashore et al. (1989) a port is defined as an input or output stream. A port is defined by its parameters and its data. The tools can be linked together to form tasks by making the different ports communicate with one another (Figure 11).
Parameters and Ports
Parameters.— We can define any processing program with two sets of parameters:
The data description parameters (e.g., number of time samples)
The process description parameters (e.g., plotting interval).
The interface to the exterior world of any processing program may be viewed as a list of values which are fetched and put. This interface obtains the parameters from somewhere (to be defined later) and passes the parameters to the different application modules. From where may the value come? The programmer does not have to worry about the source. The purpose of a parameter manager (see Figure 12), is to decide which parameter definition to take. The initialization of a parameter may depend on what transpired during the user interactive session, on the run of other modules, or it may come from a history (a session history or a processing history). Such a parameter manager may exist only if a standardization of the program communication and description exists. SEP auto-writer (Claerbout, 1986) is a good example of a standardization of program interfaces and a similar idea will be used to describe program interfaces (See Section 4.1.3). The parameter manager will play the role of a blackboard. Every module will write on the blackboard what it needs and what it can provide. This allows the possibilities to provide knowledge to a problem outside its own domain. The modules are independent and influence each other by responding to and modifying information on the blackboard.
Ports.—A module may have several input or output data flows or streams. Module’s input or output ports specify the data that can flow into or out of the port. As in Bashore et al. (1989) the ports are elevated to the level of objects. The specification of the input and output type provides a mechanism to define a structure of the tools and objects of the system. Thus planning a work is supported even if no well-defined structure of the underlying domains can be identified. This object-oriented description of the module allows the introduction of the concept of context of a command.
The concept context allows a user to make use of that knowledge and the level of structure that has been reached on a domain. This knowledge is represented by means of a set of tools and objects which are relevant in dealing with a certain task, i.e., modules which are inside a certain class of task. Additionally, a context can contain links to related or subordinate contexts, e.g., a program relates two different input or output ports, thereby reflecting the division of tasks into less complex tasks. For example, the task of doing NMO is split into a task of finding the right velocity field, and a task of reading the data. Another example of a tool linking two different contexts is a program transforming velocity information into density information.
Programming Interface.—To define the interface to the exterior world of a processing program the application developer can use a macro-language which will define what are the input and output ports of the program. This description will then be used to generate source code, documentation and data base records. The data base records are then used by the planner and the graphic tool editor (cf Figure 2). Starting from the SEP auto-writer, a description language was designed for value fetching and putting. The parameters are associated with ports which are different classes of input history or header information. The following example describes the input interface of an NMO program which needs a convergent flow of seismic data (DataFile) and a velocity model (VelFile).
A program is a particular instance of a class of programs. The program class defines the class of the input and output ports of the program. The parameters of the program are associated with a port, and are described as attributes or characteristics of this port. The port class defines what is the type of a parameter and, if any, what is the default value of a parameter. If a module needs specific parameters these parameters may be obtained from a generic object named Input. Each program class may have a certain list of parameters associated with this Input port.
Inside a program interface description a From block describes an Input port, and a To block describes an Output port. The programmer can use the default parameter of the port or overload some default parameters definition. For example if a generic class of NMO program exists the interface description of a new NMO program (newNMOProgram) may be constructed as shown in the following example:
The default class parameters of the ports DataFile, VelFile, will be retrieved automatically, and a new parameter deltam will be retrieved through the generic Input port. These macro-descriptions allow a standardization of all the programs of type NMO.
In addition this description mechanism permits these programs to be easily used as subroutines. A declaration:
generates a call to the subroutine newNMOProgram. The right calling sequence with the correct list of parameters is generated automatically.
This programming interface checks the usage of the programs and ports, provides a standardization of the programming environment, and a standardization of the program communications. The auto-writer provides a CASE for seismic applications.
A task is a chain of at least one tool that is included in a processing procedure. A task is itself a tool, so it has the same attributes as a tool (history files, parameters, icon, etc.). The simplest task procedure combines tools using UNIX pipes (Figure 13). The procedure can also include loop statements or IF statements as shown in Figure 2.
A particular control panel can be associated with a task, allowing the user to specify a particular interface with predefined parameters, computed parameters, and interactive parameters (Figure 14). The user can then create his own tools using existing ones. The task is a self-contained, executable module which may be operated interactively from its front panel, or programmably by using it in an another task of higher level. The result is a construction environment in which the user can rapidly combine, interchange, and share modules with other users to build custom applications.
The task is a central concept underlying SeisView. SeisView users may develop applications by building tasks which perform various functions and when combined, build applications.
According to Gram (1986) an important capability of any interface system is the recording of events and user actions. The purpose of this is to allow users to:
Ask questions about past events and actions.
Repeat previously performed operations, possibly editing these operations before execution.
Return to an earlier state of the system by undoing operations.
History recording may also be used by the system to build a profile of the user that can enable the system to customize its actions and respond in an intelligent manner. The history is recorded in several ways:
Collected per user and also per session for accounting and user tracing purpose.
Collected in the context for the undoing and redoing of commands.
Entered for each object showing its own history thereby permitting for tracing and controlling shared objects.
Entered as a complete history of all events for recovery, statistical analysis, planning, etc.
A history is considered to be a sequence of events occurring at different moments. Since events may happen concurrently, it may be necessary to record several occurrences at one moment. An event is the command, a parameter, a result, a context, a user, a resource, etc.
In SeisView, there are two main types of history: (1) the processing history which defines what actions have been performed on the data, and (2) the session history which defines the last parameter definitions used when the program was run. The processing history is data dependent and can be seen as a “reentry” history. The session history is not data dependent but program dependent and can be described as a “restart” history or an environment history. The SeisView parameter manager stores the processing sequence and all the current processing parameters which have been applied. The user can then recall these histories to start or redo some processing.
As in Bashore et al. (1989), the rules will express common sequences of processes and also the context of the execution of a command. There are two kinds of module rules: the rule which suggests processes immediately before the module (i.e., supplying input or correct input to the module), and the rule which gives the user some hints about what to do next with this output. The first class of rules is described under the label From history and are rules which describe a good practice. The second class of rules is described under the label To history and will advise what to do next.
A module rules example is given below: The syntax of a rule is a prolog like syntax.
The second rule shows the communication between an interactive interface and rules. The Movie program will display the data and set the flag accept.
A planner is typically given a description of some initial state and a goal, and then activated. The planner constructs a plan that depends on context conditions in the initial state.
In a STRIPS like language (Fikes and Nilsson, 1971) a processing program may be seen as an operator where the precondition or applicability condition is defined by the input ports, and the add list is defined by the output ports. The world model will be the processing history. The STRIPS model is very limited but allows reference to a known methodology. Using means-ends analysis, STRIPS attempts to find a sequence of operators transforming the initial world model into a model which satisfies a given goal. I have introduced hierarchical planning by using the notion of class and object. There are many problems which can be solved by the planner:
The user may want to do something which may be at the end of a processing sequence.
The goal is to do the minimal processing between the current state of the data and the goal.
From one session to another session the user changes only a small set of parameters. The goal is to do only what is necessary, to check the consistency of the modifications, and if they are found inconsistent, to ask the user for complementary information.
Help the user decide what to do next.
Define tasks and determine the behavior of the group of tools as a whole.
Infer plans from trace execution.
A program is a goal which can be achieved by trying to achieve the preconditions of these operators, i.e., by trying to achieve the subgoals or input ports. Once the preconditions are achieved the consistency of the utilization of a program with the input rules is checked. If a rule can not be evaluated at planning time, a conditional plan is generated.
If the preconditions are valid the planner checks to determine if the program may actually be applied. If the preconditions have not changed between two evaluations of this operator, nothing need be done. Otherwise, the operator is appended to the plan. This algorithm permits the minimal number of operations to be used to perform a task. The research of the precondition is generally done on program classes, and this phase tends to find a “good” program inside the selected class.
The module recommended may be a particular program or a class of programs. The planning of a task will then be done in a hierarchical manner: first, the planner determines the class of programs needed to complete a certain module. Next the planner determines which particular program of the selected class is “best” regarding the current context. The establishment of the link between this generic object and a real object may involve more planning activities. The same remarks can be applied to a port. The ports which describe module relation rules are class objects. Many processed data sets may be instances of the requested port class. The planner will select the “best” processing theory.
Status of Work
In its current state, SeisView provides the means to construct simple and complex seismic interfaces. Integration of functionalities such as on-line documentation and dependency provides a high-level designing environment. SeisView provides an object-oriented apporach to design and manages new interactive programs. By use of a wide and extensive range of tools, SeisView provides consistency across applications.
To chain the different applications SeisView proposes a scheme of development which includes an object-oriented interface to Fortran programmers. All communications between the interface and the application program are described using a simple language. The standardization of the batch programs implies an easier learning of the system, and the possibility of constructing a planner to structure the seismic processing world.
A general graphic environment will be given to the interpreter; file browser, application browser, history browser, graphic interface builder, task builder, and graphic planner. Object-oriented methods of communication between the different modules will be implemented.