Technical Field

This invention relates to the creation and the provisioning of special customized telephone network services for telephone subscribers and, more particularly, to a portable, visually programmed call processing logic interface for creating and provisioning such customized services.

Rfkfrnmid nf the Invention

New telephone services are continually being developed by telephone service providers in order to meet the needs of their customers. As such services become available, the telephone companies, subscribers and the users seek yet further improvements in these services. Special services such as 800 service, 900 service, and Private Virtual Networks (PVN) are only a few of the possible services being offered. Other services might well be conceived and might well find extensive use. Unfortunately, however, new telephone services have heretofore required long and expensive design, testing and deployment activities. Such special tdecommunications services are typically provided in the public telephone network by computer program call processing sequences residing in digital switches. A typical approach to providing such special services is the introduction into the telephone network of a service implementing network element which interacts with the telephone network so as to implement the telephone services. Such service implementing network elements are variously called Service Adjuncts (SAs), Service Switching Points (SSPs) and Service Control Points (SCPs). One such Service Adjunct is disclosed in S. M. Lin and J. F. Rizzo patent 4,878,240, granted October 31, 1989. A typical Service Control Point is disclosed in J. J. Bernardis patent 4,782,517, granted November 1, 1988. Finally, a typical Service Control Point is disclosed in J. O. Boese et al. application Serial Number 453,042, filed December 12, 1989, a continuation of Serial Number 125,463, filed November 25, 1987, both assigned to applicants ^* assignee. Each such service implementing network element is equipped with a set of software-implemented service primitives which can be combined in various way to implement a number of telephone services. A set of such primitives for a Service Adjunct is disclosed in the above-mentioned Lin et al. patent. Another

set of primitives for a Service Switching Point is disclosed in die above- mentioned Bernardis et al. patent. Yet another set of such primitives for a Service Control Point is disclosed in "Business Services Database (BSDB): A Service Control Point (SCP) Application Designed to Support Private Virtual Netword (PVN) Service," Technical Advisory TA-TSY-000460. Issue 2, February 1988, published by Bell Communications Research, Inc., Red Bank, New Jersey. All of these sets of senice-implementing primitives are, as a group, generally equivalent, although each is implemented in a slightly different way.

A telecommunications network including such programmable special service implementing components is called an Intelligent network." Such networks make it possible to offer useful and profitable new services such as 800 service, Alternate Billing service and Private ^' Virtual Network service. Intelligent Network Call Processing Logic (INCPL) is the name given to the software that "stitches together" die appropriate service primitives to enable the Intelligent Network mechanism to implement and customize such services without d e need for new switch software or hardware. Currently, mis INCPL is custom- developed for each new service by a service designer, usually associated with the service provider, installed in the intelligent network service implementing component and supported by a service management system for that service. Thus, instead of die software to support a new service coming from a switch vendor, it can now come from a service vendor, making it possible to reduce die interval between service concept and service offering. Unfortunately, a great deal of time is still required to design custom and implement each new service. Moreover, since such service designs are not highly portable, further delays arise due to the need to provide widely distributed software elements to support the new service in a wide variety of different environments.

Summary of the Invention

In accordance with the illustrative embodiment of the present invention, these and other problems are overcome by providing a user-friendly environment in which intdugent network service primitives can be assembled into telephone services utilizing die graphic capabilities of a computer workstation. If a complete telephone service is analyzed as a graph consisting of nodes and edges, the nodes represent the intelligent network service primitives executable by the service implementing components and tiie edges represent d e

order of execution of these primitives. Both action nodes and decision nodes can be defined in terms of the available service primitives and stored for later use in designing a new tdephone service. Moreover, witfi this representation, the new tdephone service can be displayed as a "tree" of such node primitives. Such a tree display can be manipulated graphically to create and alter the logic of a service. An interpretor program, designed for a particular service implementing component, implements such display representations with d e available adjunct service primitives. i accordance with this invention, tdephone services can be created, manipulated and altered by simple, user-friendly graphical manipulation. Not only can intdugent network service primitives be assembled graphically into new services, but service features can be defined as assemblies of such intdugent network service primitives and, once designed, stored in a library as a single node to be invoked and reused as a single entity in designing a plurality of future services. More particularly, graphical images or icons on a display screen are used to represent a reusable library of user-defined telephone service primitives. These images or icons can be manipulated graphically so as to assemble the images into logical trees representing new services or new service features. Once fully assembled, me electronic representation of the graphical service tree or service feature tree can be interpreted so as to actually implement the service or service feature. In this way, new telephone services can be designed and implemented much more quickly than in the prior art and thus save much of the expense previously associated with telephone service design and deployment. In addition, the extremely high level representation of telephone services implicit in die graphical service trees is an extremely portable mechanism for quickly and easily deploying such services without extensive reworking of service implementing code. Indeed, die simplicity, speed and flexibility of telephone service design and implementation provided with the present invention can be exploited to allow each individual tdephone user to custom design telephone services exactly matching the needs of the customer.

The present invention makes possible dynamic graphical creation, customization and provisioning of new call processing services. Using both simple, predefined primitive nodes and complex, user-defined constructed nodes, new services can be defined rapidly and with great ease. A new service is

created visually as a logic tree with nodes defined to represent a high-level abstraction of die primitive call processing actions or call processing decision points or combinations of such primitive actions and decision points. This tree, or die dectronic representation of die tree, is called a Call Processing Record (CPR) since it defines exhaustively the processing necessary to provide an individual call with the defined service. Service providers, as well as subscribers themselves, can customizr, and provision the graphically defined service to satisfy specific customer needs by dynamically modifying and parameterizing the relevant graphical call processing record trees. The thus provisioned call processing records representing the service can then be translated from the user- friendly visual format to a rigorous program-generating format which can be genericaUy interpreted by existing service implementing components. The distribution and installation of such call processing records to appropriate service implementing components in an intelligent network enables die thus-described service to become instantly available to tdephone subscribers.

There are three steps in this service specification process: 1) defining d e node primitives, 2) establishing which nodes can be used in a particular service, and, 3) creating call processing records defining a particular service using die nodes that have been defined, and to which can be added die customer-specific parameters necessary to completely specify the service. These three steps can be iterated interactivdy to improve die quality of the resulting service, to remove "bugs," or to provide new features and capabilities.

Other aspects of a service creation and provisioning system are disclosed and claimed in e copending applications of D. L. Babson, J. A. Bajzath, Jr. and T. C. Ely, Serial Numbers , all filed of even date herewith and assigned to applicants' assignee.

Brief Description of the Dra ing

A complete understanding of die present invention may be gained by considering die following detailed description in conjunction with die accompanying drawings, in which:

FIG. 1 shows a block diagram of an intelligent telephone network including a graphical telephone service design and deployment system in accordance with d e present invention;

FIG. 2 shows a flowchart of the service definition, provisioning and implementation processes taking place in the system of FIG. 1 ;

FIG. 3 is a graphical representation of a display screen used to define new tdephone service primitives in the system of FIG. 1; FIG. 4 is a graphical representation of a display screen used to define die allowable subset of tdephone service nodes which are used to design and implement a particular advanced telephone service in die system of FIG. 1 and

FIG. 5 is a graphical representation of a display screen used ID customize a logical tree template of service primitives by spedfying all of the customer-dependent variables required to implement a particular new service for a particular customer in die system of FIG. 1.

To fadlitate reader understanding, identical reference numerals are used to designate elements common to the figures. Detailed Description

Referring more particularly to FIG. 1 of the drawings, tiiere is shown a general block diagram of an intelligent network telephone service design and deployment system comprising a workstation 10 for designing new telephone services in accordance witii die present invention. As will be described hereinafter, workstation 10 indudes graphical facilities for defining customer special service nodes in terms of service control point primitives, bounding new special services in terms of the thus defined nodes which can be used for that service, and assembling these telephone service nodes into templates or assemblies of call processing logic units capable of providing die new telephone special services. Service creation process 11 provides the software for supporting these facilities and indudes standard window processing capability as wel as mouse or other visual selection apparatus support, and is typically stored in the program memory of workstation 10. Storage device 12 stores a library of She electronic representations of all of the nodes previously spedfied, both simple primitive nodes and more complex, user-defined service feature nodes. Storage device 13 stores d e definitions of all of the services defined at workstation 10 _r where a service definition is simply the specification of which of the defined nodes (primitives) can be used to implement a particular service. Storage device 19 stores templates of multinode fully designed services as call processing

records. In d e present application, a "template" is a fully designed service, but without all of die variable parameters which are dependent on die actual customer using die service. Although shown as separate storage devices, stores 12, 13 and 19 can be contained in a single storage device. The present invention contemplates three steps in creating new services, defining graphical nodes from which services can be assembled (node definition), prescribing which nodes can be used in a particular service (service definition) and prescribing the logical interrelationships of die various nodes necessary to produce die desired service (call processing record creation). As new nodes are defined, they are stored in node library 12 for later retrieval and reuse. Once a new service is fully defined in terms of primitive or complex service nodes, a representation of that service definition is stored in a service definition storage fadlity 13. Once die service nodes are assembled into a service logic tree or template, that template is stored as a call processing record (CPR) in call processing record template library 19. The templates in library 19 require only the specification of certain customer-dependent variables required to fully implement me service for a particular customer.

A services management system 14 provides administrative control over a plurality of service control points such as service control point 17 which actually implement the new services by exchanging network control messages with die switched tdephone network 18. The details of the service control point 17, along with its interaction with die switched telephone network 18, are detailed in die aforementioned copending application of J. O. Boese et al. Since die structure and operation of the service control point 17 and die switched telephone system 18 comprise well-known telephone fadlities, they will not be further described here. Suffident to note mat these elements are able to implement tdephone network service primitives which can be utilized to realize tdephone services and which are similar or identical to tiiose disdosed in the aforementioned J. J. Bernardis and S. M. Lin patents and BSDB publication. Associated wim die services management system 14 is a customer data base 16 which contains detailed information concerning die customers utilizing telephone network 18. Also assodated witii services management system 14 is a further computer workstation 15 which can be used to add customer preferences and otiier customer speάfic data to die service templates

defined in store 19. This addition of d e customer spedfic data to a service template is called "service provisioning" and permits the service templates passed to service control point 17 to be customized for a particular customer or set of customers using network 18. Workstation 15 can, of course, be combined witii workstation 10 if die two workstations are at d e same location.

The workstations 10 and 15 can be any modern workstation supporting graphical manipulation capability. One such workstation is the SUN 3/160 terminal running under d e SUN operating system and using die SUNVIEW* graphics environment. This environment provides window support, mouse control, and graphic creation and mampulation capability adequate to implement die present invention. Many other modem workstations, however, would likewise support implementations of die present invention.

The present invention will be better understood by considering d e flowchart of FIG. 2. In FIG. 2 there is shown a flowchart of the process for designing and deploying new services for telephone subscribers in accordance with die present invention. Three major steps are involved, node definition, service definition and call processing record creation. These steps will be taken up individually below.

The intended user of die process of FIG. 2 is the service creator, typically die telephαie service provider. As suggested in box 20 of FIG. 2, this person must create the nodes to be used in new services. The new nodes are created dynamically by specifying the following properties of the new node.

1. Node Name

2. Node Type 3. Data Type

4. Node Rules

5. "Other" Allowed

6. Node Error Message

7. Notes As is shown in detail in FIG. 3, a node definition screen can be used to capture the node properties as data items. The "Load," 'Validate," "Store," "Delete," "Browse," "Help," and "Quit" command buttons are utilized to access and process nodes as entities. The data acquisition fields are used to define new nodes by spedfying d e node name and the node properties. Using

these properties, a node can be administered by the service management system 14 of FIG. 1 and implemented by die service control point 17 of FIG. 1 widiout die necessity of writing new service implementing code. As illustrated in FIG. 3, me user is presented witii an on-screen form which requires that the user specify die values for each of these properties. The cursor initially is located at die first data field (NODE NAME:) and advances to successive data fidds as the <enter> or <retura> key is depressed. Once these properties have been specified, the user can store die completed node definition for the newly created node in a node library in store 12 (FIG. 1), using die command keys identified in die top portion of die screen display of FIG. 3.

The properties captured by die node definition screen of FIG. 3 contain key information about die new node and, when necessary, can be translated and sent to the service control point 17 of FIG. 1 to drive a generic Call Processing Record (CPR) interpreter (such as that disclosed in die aforementioned Bemardis patent), so that it can support the use of this new node in any call processing records that are created and provisioned for services. Additional or supplemental properties, such as assodated service control point call variables, node connection rules and node translation rules, can be added to die node library at a later time to completely characterize the meaning and intent of these operations at a particular services management system 14 and a particular service control point 17 (FIG. 1) in a generic manner. More particularly, a specific identification of die service implementing primitive in one or more service implementing network components which can be used to realize the node can be expliάtiy added to die node definition. The presence of such an identification of die actual code sequence in die service control point would substantially simplify the design of die interpreter program which translates the call processing record into actual service implementation. In this sense, die nodes become dements of an extendible, high level programming language for specifying telephone services. In response to die NODE NAME prompt, the user supplies any unique name chosen for die new node. This name will hereafter be used to identify die node. This new node name can be thought of as a higher-level abstraction representing a spedfic operation using pre-defined call processing variables. Nodes can be eitiier dedsion nodes or action nodes. The following

node types, supplied in response to the NODE TYPE prompt, are possible:

TABLE 1 NODE TYPES

The node type sdected provides information mat can be used during call processing record validation and call processing record code generation. These node types correspond to all of die basic types of actions and decisions that might be utilized in providing telephone spedal services. They are already programmed or programmable into prior art service implementing network components such as service control point 17. Should a new type of node be required, however, it is necessary to specify die new type, and to provide generic implementation of die activity of the new node type in die service control point 17.

The node types have particular meaning to service control point 17, which must execute die call processing record in real time. Spedfically, die node type informs service contrd point 17 what functions or call primitives are to be invoked. These node types thus represent die "programmed capabilities" of service control point 17, which, when combined with the node

name, representing a particular pre-defined call variable in die service control point call processing execution environment, enable service control point 17 to actually perform the requested operations using die correct data.

The DATA TYPE fidd spedfies the format of die data that will be acceptable as input values for tiiis node when this node is used in a call processing record. The data formats allowed are dedmal numbers, alphanumeric text, tdephone numbers, trunk identifiers, variable data, and billing information. The data type is used during call processing record validation at die time the call processing record is "provisioned" by d e specification of customer-dependent data values.

To administer a call processing record, services management system 14 of FIG. 1 must be able to determine whetiier valid values have been entered for die nodes in die die call processing record tree. Therefore the user must spedfy the rules to be used when validating die input values for this node when this node is used in a call processing record. In accordance witii die present invention, a regular expression can be used to represent die validation rules. Moreover, such validation rules can be entered dynamically in die node definition as opposed to hard coding d em in a program. For example, to specify die validations for a queuing node, die user can spedfy the regular expression "~(lifo I fifo)$". This expression states that die node can accept either 'last in, first out" or "first in, first out" queue behavior as input values.

In response to die OTHER ALLOWED, prompt, the user must spedfy whether the node can accept the word "otiier" as an input value. For example, if a day of the week node were defined and available for a particular service, a call processing record would be constructed with d e day of the week node in the tree. If the input values for die day of die week node were spedfied as "Monday and Tuesday," tiien a second branch would need to be created to cover what should be done on Saturday, Sunday, Wednesday, Thursday and Friday. Ratiier tiian spell out the remaining days, die string "other" could be used. For some nodes "otiier" is not a sensible value. Therefore, during node definition, d e user must indicate whetiier "other" is a valid input value or whetiier entering "other" should result in a validation error.

In response to the NODE ERROR MESSAGE prompt, the user enters a string to be printed when an inappropriate input value is spedfied for a

node during die provisioning of a call processing record. This allows "on the fly" validation of data entries during all succeeding uses of this node definition.

The NOTES prompt permits a convenience fidd for die user. It can be used to note limitations on the node behavior, a general functional description of the node or any otiier information die user wishes to associate with die node definition.

Also shown at die top of screen 30 of FIG. 3 are a series of command light buttons labeled "Load," 'Validate," "Store," "Ddete," "Browse,"

Ηdp," and "Quit." These command buttons axe operated, for example, by a mouse-driven cursor, to accomplish die assodated screen display control functions. For example, "Load" will load any particular previously existing node definition (e.g., for editing) simply by giving die node name and evoking the

"Load" command. Similarly, "Validate" performs the validation on die data entries made in response to die prompts. "Store" stores die newly defined node in the node library 12 of FIG. 1. The "Ddete" command ddetes die identified node definition from library 12. "Browse" allows die user to browse through all of die previously defined nodes, Ηdp" provides screens of useful andllary information likely to be of assistance to die user during die node definition activity, and "Quit" allows die user to terminate die node definition activity. The implementation of these so-called "command buttons" are well-known in the art and will not be further described here.

Returning to FIG. 2, die second box 21 represents the activity of defining a new service in terms of previously defined nodes. In tiiis context, a "record" is a service definition and box 21 indudes "Load," 'Validate" and "Store" commands for these service definition records. In addition, box 21 indudes "Canvas" commands. These commands permit die visual and graphical manipulation of previously defined nodes into service definitions. As can be better seen in FIG. 4, the left half of die screen 40 is die drawing area where visual representations of previously defined nodes can be assembled into service definitions. The "Canvas" commands indude "Clear" (to dear die canvas area), "Draw" (to prepare for manipulating items on the canvas), "Help" (to obtain screens of useful information to assist in me use of the system), and "Quit" (to terminate die service definition session). In addition, individual items in the canvas area can be manipulated with die commands "Select" (to select a

particular node), "Add" (to add a selected node to die service definition), "View" (to view die node definition of the selected node), and "Delete" (to delete a node from the service definition).

The intended user of the service definition process is the service creator. This creator utilizes the service definition process to define the subset of nodes in the node library that are to be used in a specific service. The user is presented with die form shown in FIG. 4 which enables the user to spedfy the nodes from the node library tiiat are allowed for use by a specific service with a certain qualifier. A qualifier could, for example, be a specific area of service in the service provider's territory. With die functions described above, die use of any particular node in a service can be defined by a service creator and administered by die service management system 14. Once the allowable node names for a particular service have been spedfied, using the screen 40 of FIG. 4, the user can store die service definition for die new service in service definition tables 12 (FIG. 1). These service definitions can thereafter be edited, augmented or deleted from die service definition tables 12 whenever desired.

The service creation user can distribute the node library and die service definition tables in store 12 to the generic service management system 14 for use in administering die new service. Services management system 14 will permit the use of only die specified subset of nodes in all call processing records tiiat are created and provisioned for this particular service. Additional properties, such as service-specific node connection rules and node translation rules, can be added to die -service definition tables at this time to completely and generically characterize die meaning and intent of these operations for the service management system 14.

Returning to FIG. 2, the box 22 represents the procedures for "provisioning" me service defined in box 21. In this regard, die term "provisioning" means creating the logic tree representing die new service and customizing die defined service in terms of node parameter values. The screen 50 of FIG. 5 illustrates a mechanism for carrying out this process. The service creator can use this process to define a default representation of the service offering as a template of nodes interconnected in a call processing record tree format. The allowed nodes for a particular service are die ones spedfied through die service definition process. The service provisioning user can use tiiis

process to customize the default service template and to provision die service witii node parameter values. The user is presented with the visual programming tool illustrated in FIG. 5 to enable a graphical, user-friendly specification and input of die appropriate service customization and provisioning information, based on service, qualifier and customer key information. The qualifier could be, for example, a specific area of service in die service provider's territory. The screen of FIG. 5 provides record manipulation functions (Load Record, Validate Record, Store Record, and Translate Record), node manipulation functions (Place, Offw* Move, Edit, Disconnect, and Remove), and draw commands (Sdect, Clear, Hdp, Quit, and Redraw).

With d e above described functions, the user can define a service template of nodes interconnected in a call processing record tree format as a default representation of die service offering. Furthermore, me true power of die present invention becomes evident when it is realized tiiat die service creator can define modular templates of common reusable node-based logic as service features, which can then be added to die node library as nodes for reuse by other features and services. In effect, the present invention provides a mechanism for using die set of "programmable capabilities" available at the service control point 17 and define reusable, user-friendly and high-level modules mat enable easier and faster visual programming of me call processing logic.

It should be noted tiiat assemblies of low level nodes can be associated togetiier into a higher levd capability which, once given a name, can be retrieved, manipulated and used in creating new services just like a low level node. In tiiis way, as time proceeds, die creation of new services becomes easier and easier since ever higher levds of service primitives become available for assembly into die new services.

Once the default service template has been spedfied, die user can store die service template definition for d e new service in service template definition store 19. The user can tiiereafter distribute these service template definition tables to the generic services management system 14 for use in administering die new service, providing a default service logic flow for the purpose of provisioning. Furthermore, die availability of service node definitions in store 13 will ensure that provisioning will support die use of only the creator- spedfied subset of nodes in any call processing records that are customized and

provisioned for this particular service.

The service provider or die subscriber can also use die process illustrated in FIG. 5 to customize the default service template and to provision die service by providing node parameter values. At tiiis stage, the node values supplied are validated dynamically by invoking die node validation rules spedfied for each node name in the node library. Additional node and service definition properties, such as node connection rules and node translation rules, can be specified to drive die validation and translation operations at die services management system 14 in a generic manner. The attached Appendix provides psuedocode for implementing die flowchart of FIG. 2. With this pseudocode and die description herein provided, any person of ordinary skill in the programming art is able to fully implement the present invention.

It should also be clear to those skilled in die art that further embodiments of the present invention may be made by those skilled in the art without departing from the teachings of the present invention.

APPENDK Pseudocode

Node Definition Process Pseudocode invoke ('node.definition') do until (invoke ('quit')) if (view (node.definition)) tiien input (node.name) invoke ('load') if (node.definition (node.name) in library then retrieve (node.definition (node.name)) display (node.definition (node.name)) else create (node.definition_window (node.name)) display (node.definition_window (node.name)) endif end.invoke endif if (spedfy (node.properties)) then set.default (field.values (node.name)) enter (field.values (node.name)) else if (modify (node.properties)) tiien update (field.values (node.name)) endif endif if (validation.check (node.name)) men invoke ('validate') verify (node.name, field.endies, field_ent___y_combinations) end.invoke endif if (store (node.definition)) then invoke ('store') retrieve (node.definition (node.name))

σverlay (node.definition. node.properties) store (overlay (node.name)) end.invoke endif if (ddete (node.definition)) tiien invoke ('delete') retrieve (node.definition (node.name)) ddete (node.definition (node name)) end.invoke endif if (browse (node.definition) tiien invoke ('browse') display (node.properties) retrieve (node.definitions) display (node.definitions) end.invoke endif end_do

Serv e Definition Process Pseudocode invoke ('service.definition') do until (invoke ('quit')) if view (service.definition) then input (service.name, service.qualifier) invoke ('load') retrieve (service.definition (service.name, serivce.qualifier)) display (node.name.Iist) end.invoke endif if view (aU.nodes) men invoke ('select') generate (menu (aU.nodes)) end.invoke endif if (select.node) then invoke ('sdect') select (desired.node, menu (aU.nodes)) display (desired_node, current.node.display) end.invoke endif if use (current.node) then invoke ('add') position (current.node, canvas) add (current.node, service.definition) end.invoke endif if disallow (current.node) then invoke ('ddete') sdect (current.node) delete (selected.node) end.invoke endif

if view (current.node.definition) then invoke ('view') sdect (current.node) display (node.definition, current.node) end.invoke endif if validate (service.defimtion) tiien invoke ('validate') verify (field.entries, service.definition) verify (fidd.entry.combinations, service.definitions) end.invoke endif if store (service.definition) tiien invoke ('store') retrieve (service.definition (service.name, service.quaUfier)) overlay (service.definition (service.name, serivce.qua fier), canvas.nodes)) store (service.definition (service.name, service.quaUfier)) end.invoke endif if dear (canvas.area) then invoke ('dear') dear (aU.nodes, canvas.area) end.invoke endif if redraw (canvas.area) then invoke ('draw') dear (aU.nodes, canvas.area) auto.invoke ('load') end_invoke endif end.do

CPR Input Process Pseudocode invoke ('CPR.input') do until invoke ('quit') if view (existing_CPR.tree) then input (service.name, qualificr.name, customer name) invoke ('load') retrieve (node.names (service.name, service.qualifier)) retrieve (node.definitions (node.names) retrieve (CPR.tree (service.name, service.quaUfier, customer.name)) display (CPR.tree (service.name, service.quaUfier, customer.name)) end.invoke endif if view (aUowed.nodes (service.name, service.quaUfier)) then invoke ('sdect') generate (menu (aUσwed.node.names)) end.invoke endif if select (aUowed.node) then invoke ('select') identify (desired.node) display (desired.node, current.node) end.invoke endif

if add (current.code, CPR.canvas) then invoke ('place') position (current.node, CPR.canvas) place (current.node, CPR.canvas) end.invoke endif

if connect (node.namel, node_πame2, CPR.canvas) then invoke (connect)

select (from.node) select (to.node) draw.Une (from.node, to.node) end.invoke endif if move (node.name) men invoke (move) erase (node.name, old.location) redraw (node.name, new.location) redraw (connections, old.location, new.location) end.invoke endif if edit (node.name, node.value) then invoke ('edit') sdect (node.name) display (edit.menu) input (node.value) invoke ('enter') erase (old.value) display (new.value) end.invoke end.invoke endif if disconnect (node.name) men invoke ('disconnect') select (node.name) erase.connection (node.name, node.parent) end.invoke endif if remove (node.name) then invoke ('remove') select (node.name) remove (node.name, children, connections) end.invoke endif if vaUdate (CPR.node)

then invoke ('vaUdate') for (each node in CPR.tree) do vaUdate (node.value, node.rule) end.do display (error.messages) correct (node.values, connections) end.invoke endif if store (CPR_tree) tiien invoke ('store') retrieve (CPR.tree (service.name, service.quaUfier, customer.name)) overlay (CPR.tree (service.name, service.quaUfier, customer.name), CPR.tree (canvas.area)) store (CPR.tree, overlay) end.invoke endif if dear (canvas.area) then invoke ('dear') erase (canvas.area) end.invoke endif if redraw (canvas.area) then invoke ('redraw') erase (canvas.area) auto.invoke ('load') end.invoke endif

end.do