Method and apparatus for automated conformance and enforcement of behavior in application processing systems5677997Abstract A model information control system ("MICS") is used in conjunction with a user-defined information model and one or more conventional information system program modules or "functions" to execute business applications. Following each execution of an action defined by the information model, an Expected Behavior Control System ("EBCS") determines if the resulting behavior is consistent with expected behavior and conforms the behavior to the expected behavior if necessary. The EBCS may also change the behavior of an application processing system or application program by enforcing a new behavior for the application processing system or application program without modifying them. The MICS includes an event-action-state machine that manipulates the user-defined information model and the functions. Claims What is claimed is: Description TECHNICAL FIELD
______________________________________
MODEL MEDICAL
______________________________________
#OBJECT PATIENT CHART,PRIMITIVE,DATABASE
ACNT NO,TYPE=1,LEN=8,GROUP=100,FPROT
DEFAULT VALUE
›ACNT NO! = SEQNUMBER.
VISIT FIRST,TYPE=d,GROUP=100,FPROT,SETDATE
LAST,TYPE=D,GROUP=100,FPROT,SETDATE
PATIENT NAME,TYPE=A,LEN=30,GROUP=102,MFILL
ADDRESS,TYPE=A,LEN=30,GROUP=103,MFILL
CITY,TYPE=A,LEN=15,GROUP=104,MFILL
STATE,TYPE=A,LEN=2,GROUP=104,MFILL
ZIP CODE,TYPE=L,PTYPE=Z,LEN=5,GROUP=104,MFILL
BIRTHDATE,TYPE=D,GROUP=105,MFILL
SEX,TYPE=A,LEN=1,GROUP=105,MFILL
Constraint,values
M - MALE, F - FEMALE.
MARITAL STATUS,TYPE=A,LEN=1,GROUP=105,MFILL
Constraint,values
S - SINGLE, M - MARRIED, W - WIDOWED, D - DIVORCED.
PHONE NO(HOME),TYPE=S,PTYPE=P,LEN=10,GROUP=106,RJUST
(OFFICE),TYPE=S,PTYPE=P,LEN=10,GROUP=106,RJUST
SOCIAL SEC.#,TYPE=L,PTYPE=S,LEN=9,GROUP=107
DRIVER LIC.#,TYPE=C,LEN=15,GROUP=107 . . .
______________________________________
The first field in the first line includes the object's name (in this case PATIENT CHART). The second field in the line includes the object type flag identifying the type of object (in this case primitive). Following the object type flag, the next field identifies the action type flags that identify the one or more actions that the CSE can select for activation, instantiation and processing of instant(s) of an object. In this example, an object having the DATABASE action class flag merely indicates to the CSE to substitute all actions associated with the DATABASE action class as available actions (thus making it unnecessary to individually list each action of the set). Following the object type and action type control flags on the first line of the object, the object includes a set of attributes. As can be seen, the patient chart object is used for accounting and information purposes and thus includes such attributes as name, address, date of last visit and account number, as well as others. The object further includes a number of presentation control flags that are associated with particular attributes. As noted above, the GROUP flags in the attributes are used to group different attributes of the object on the same line of the interface display. Thus ACNT NO, VISIT FIRST, and LAST attributes will be presented on the same line. An attribute will also include a DATA statement if the same attribute is used more than once in the object. Referring now to FIG. 2, a detailed state diagram is shown of the preferred operation of the control system engine (CSE) of the MICS. The various states of the CSE and associated control actions are identified below: (1) Initialize MICS (2) Select Model (3) Select Object (4) Select Action (5) Activate Instant (6) Process Instant (7) Terminate Model (8) Terminate CSE Prior to the CSE execution, one or more information models are created by a developer using semantic rules for the target system. Each information model has one of three states: idle, active and suspended. When an information model is in its idle state, its "next state" is active. An information model in the active state can be suspended at any time during the processing of the information model. Once suspended, the information model can be returned to its active state (at the same point therein where processing was suspended) or the suspended information model can be placed back into its idle state. Each information model has associated therewith a attribute identifying its state and its next state. Execution of the control system engine begins with State 1. In state 1, the CSE is initialized. This step obtains the necessary resources (e.g., memory, buffer pools, interprocess communication environment, I/O interface environment) from the operating system and then reads the action table definitions and function table definitions and loads them into memory. The CSE also creates structure in the memory to hold the information models, and loads information models into the memory. State 1 also sets up the user environment's presentation interface 26. In State 1, all information models are set to idle and the information model attribute is set to "3" (which is the next state after selection of an idle model). The CSE then moves to State 2. If there is a failure during State 1, the CSE goes to State 8 and terminates, providing an error message or the like. In State 2, the user is prompted to select an information model. Although not meant to be limiting, preferably the presentation interface is a Windows-based graphical user interface (GUI) and a conventional point and click device is used to make appropriate selections. If the user selects a model, the CSE activates the selected model and sets an "active model" to the selected model. The activation of a model means assigning necessary storage area, initializing databases, building a dictionary from the set of attributes from all objects and creating sets of attributes with an associated attribute constraint expression or merely building a group of attributes with associated attribute constraint expression. This will be more fully shown later with respect to a calendar example. If the user decides to cancel the session, the CSE activates the most recently suspended model to "active model." The CSE then proceeds to the next state of the active model. If the user decides to exit, the CSE proceeds to State 8 and the CSE is terminated. In State 3, the CSE first determines whether there are one or more objects defined for the active model. If there is no object, set object equal to model name and copy all control flags and control expressions defined at model to object, and set all attributes of model as attributes of object. If there is only one object defined for the active model, the CSE sets "active object" attribute to this object and proceeds to State 4. On the active model, the CSE controls the presentation interface to display the list of available objects (which are defined in the information model) and prompts the user Go select one. If the user selects one of the objects, the CSE sets an "active object" attribute to the selected object and proceeds to State 4. If the user decides to cancel, the CSE returns to State 2, from which the CSE then proceeds to State 7 in which the active model is terminated. In State 4, the CSE first determines whether there is an action class flag associated with the active object. If there is one, the CSE substitutes all action flags associated with the action's class as valid action flags. If there is only one action flag, the CSE sets an action associated with the action flag to "active action" and proceeds to state 5. On the other hand, if there is more than one action flag, the CSE controls the presentation interface to display the list of action names associated with action flags of the active objects and prompts the user to select one. If the user selects one of the actions, the CSE sets an "active action" attribute to the action associated with the action name of the selected action of the active object and proceeds to State 5. If the user decides to cancel, the CSE goes back to State 3. If the user decides to exit, the CSE proceeds to State 7. If the user decides, however, to access another information model during State 4, the CSE sets the active model's next state equal to 4, suspends the active model and proceeds back to State 2. In State 5, processing begins by first setting all values of the attributes of active objects to zero except those attributes having the DPROT flag set. Then a test is performed to determine whether the active object has an associated link object. If so, the CSE activates the instant of the link object. If activation for a link object fails, the CSE returns to state 4. If the activation for the link object has been successful, or if the active object does not have an associated link object, then the routine continues by determining whether the active object requires an active instant. If so, the CSE then activates the instant using a select condition if one exists in the active object. (The select activation constraint of the object maps directly to a select call associated with the database 20). If activation fails, and there is no learn flag, the CSE goes to state 4. If activation is successful or no activation is required, the CSE goes to State 6. If activation fails and there is a learn flag, the CSE also goes to state 6 because the learn flag instructs the CSE to accept an empty instant even though an active instant might otherwise be required. For example, in an appointment calendar information model, the database will not necessarily contain the instances corresponding to all calendar dates. When the user requests to see the data for a specific page of the calendar and no data for such page exists in the database, the learn flag allows the CSE to accept the empty page as an active page with no data in it so that when the user enters the data on this page it will be entered into the database. Also, the CSE executes any activation expression if one exists for the active instant. If the user decides, however, to access another information model during State 5, the CSE sets the active model's next state equal to 5, suspends the active model and proceeds back to state 2. For each of the actions described above, such as activations of instants, assigning of values and execution of expressions a check is performed by the Expected Behavior Control System (EBCS) to determine if the processing actions initiated by the actions provide an expected behavior. For conformance of actions to a particular behavior, the checks are only performed after an action is performed. For enforcing particular process flow behavior, the checks by the EBCS may be performed both before and after the processing of actions. The EBCS will be more fully discussed in a moment. In State 6, the routine first determines if there is any function flag associated with the active action. If one or more function flags exist, then for each function flag, the CSE executes the associated function and any process propagation expression associated with the active object over all instants which satisfy activation constraints in the object. The function may be an instantiation function, e.g., a user instantiation function that interacts with the user using the presentation interface and presentation control flags. The CSE will also process any attribute flags by mapping the attribute flags into appropriate functions. For example, the presentation flags are used to create windows and control the interaction with the data in the window. Only data that satisfies attribute constraints is accepted and upon acceptance, the CSE also executes any propagation expression associated with any attribute. If the user decides, however, to access another information model during State 6, the CSE sets the active model's next state equal to 6, suspends the active model and proceeds back to State 2. If no function is associated with the active action exist or if the functions associated with the active action have been successfully executed, the CSE executes any propagation expression associated with object and the routine continues by determining if any object type flag is primitive or atomic. If not, the CSE goes to state 4 to select the next action. If yes, then the CSE determines whether the current action has an update instant or delete instant (instant propagation type action control) flag. If an update instant flag exists, active instants are updated or an empty instant is added to the database. If an delete instant flag exists, the CSE deletes an active instant and ignores empty instants. If an object has link objects, its associated link propagation expressions are executed and its instants are updated. If user selects NEXT or PREVIOUS event, the CSE obtains the NEXT or PREVIOUS instant. If user selects a PROCESS event, the CSE returns to state 4. If an error occurs during any of these activities, the CSE returns to state 4 with an event flag indicating a failure. As in State 5, for each action a test is performed for the EBCS to check for expected behavior to conform or enforce the processing actions to provide an expected behavior. In State 7, the active model is terminated and the CSE activates the most recently suspended model is one exists and goes to the next state of the activated model; otherwise the CSE returns to State 2. In State 8, the CSE is terminated. Once the CSE is initialized it executes through its various states until State 8 is reached. As the CSE executes, the functionality defined in the information model is effected in the same way as a prior art source code program executes. An exemplary implementation of several information models for use in the MICS are now be illustrated which do not utilize an EBCS. In this example, the MICS includes three information models: an appointment book (MODEL APPOINTMENT CALENDAR), a notepad (MODEL NOTEPAD) and a complex medical system (MODEL MEDICAL). The Appointment Calendar model includes a short list of attributes (such as the date, day of week, time and daily time increments) and control expressions. The initial values expression that initiate the date, the day of week and the time to current system date, day of week and time, a default values expression that sets the value of the day of week attribute to a corresponding value of the date attribute, and a constraint assignment expression that sets the date to preydate (date-1) or nextdate (date+1) based on EVENT prev and next, respectively. Likewise, the notepad model includes a short list of attributes. The medical system includes a list of numerous objects. The system control tables consisting of action and function control flags is also provided to understand the examples. ##SPC1## As can be seen, the medical system is much more complicated as compared to the simple notepad and calendar applications. Despite the length of the information model itself, however, it should be appreciated that the model is all that is required for purposes of executing the business application. In other words, once the medical system information model is written, it is not required for the user to write source code or other high level code to implement the model. It is further not required that the user maintain source code or the like to implement enhancements or to correct errors. In this regard, all the user need do is to modify the information model (e.g., by adding an attribute, modifying or adding an object, changing an expression in an object, etc.). In operation, the information model is directly processed by the CSE. The MICS may include a preprocessor to process the expressions if desired and the functions can be embedded in the MICS or can be distinct therefrom and thus executed using IPC facilities. The base MICS need not be changed or altered. With reference to the medical system information model and the function set previously described, the trace of the CSE for the exemplary system can also be seen for a system which does not utilize the expected behavior control system which will be more fully discussed in a moment: State 1: MICS initializes presentation interface and creates linked list of three models namely appointment calendar, notepad and medical system. State 2: CSE displays three models using presentation interface. Assume the user conditions the medical system. The CSE activates the medical system model and sets "active model" attribute to the medical system. State 3: CSE displays the following objects to user using the presentation interface: PATIENT CHART BILLING DATABASE PRINT BILL PRINT INSURANCE FORM DAILY RECONCILIATION BILLING? INS MNGMNT LIST OB DUE PATIENT LIST RECALL PATIENT ACCOUNT BALANCE DUE PRACTICE ANALYSIS INS CHARGE ANALYSIS PROCEDURE CODE INSURANCE COMPANY DIAGNOSIS CODE POST EXPENSES EXPENSE REPORT Assuming the user conditions the PATIENT CHART object, the CSE proceeds to State 4. State 4: CSE displays the following action associated with PATIENT CHART object using the presentation interface (note that these actions are displayed because they are the only action flags in the object and the actions associated with such action flags): ADD UPDATE DELETE VIEW Assume now that the user conditions UPDATE. The CSE then proceeds to state 5. State 5: CSE sets all values of PATIENT CHART object to null. CSE looks for initial values expression of the PATIENT CHART. There are no such expressions; if one existed it would have been executed. The primary object has no associated link object so no instant is activated for a link object. The CSE then selects data object of the PATIENT CHART. Since PATIENT CHART type is primitive, the DATA OBJECT of PATIENT CHART is PATIENT CHART itself. Because the action instant type flag of an active action is ACTIVE INSTANT and PATIENT CHART has no constraint expression, the CSE instantiates instant of the DATA OBJECT as follows: The CSE displays the following two keys using the presentation interface (because the PATIENT CHART instances are accessed by indexes or keys as indicated in the index at the end of the object): ACCOUNT NO PATIENT NAME Assuming the user enters the key value for PATIENT NAME, the CSE interacts until a valid key value is entered. The CSE also activates instant associated with PATIENT NAME by instantiating PATIENT CHART attributes using the database interface. Assuming activation is successful, the CSE looks for an activation expression associated with PATIENT CHART object. There is none here; if one existed it would have been executed. State 6: CSE first determines if there is any function flag associated with the UPDATE action. In this case there is only one function USR.sub.-- INSTANTIATION, so CSE executed USR.sub.-- INSTANTIATION function. This function displays attributes to user using presentation control flags and the presentation interface. The user then modifies the attributes and returns an "event." If event is not "process" (selection of PROCESS or NEXT or PREY EVENT), the CSE proceeds to an appropriate state described in the state 6 logic of the CSE. Assuming the selected event is "process", the CSE executes any propagation expression associated with the active object. In this case there is none. CSE then determines if DATA OBJECT associated with PRIMARY OBJECT is primitive or atomic. In this case DATA OBJECT of PRIMARY OBJECT PATIENT CHART is PATIENT CHART itself. Since PATIENT CHART is primitive, CSE then determines if active action has any instant propagation type flag. In this instant propagation type flag is UPDATE INSTANT. Since PATIENT CHART instant is ACTIVE INSTANT the CSE updates the instant of PATIENT CHART using the database interface. If "process" is a result of PREV/NEXT event then the CSE will get prey/next instant of the patient chart from the database, activate the instant and repeat state 6, else the CSE returns to state 4. In the present case, assume "process" was the result of even PROCESS, then CSE returns to state 4. This completes the processing. Referring now to the second calendar program information model, the model contains no dictionary or object. The model also does not implement the expected behavior control system. The trace of the CSE for the exemplary system in which the system learns can also be seen. State 1: MICS initializes the presentation interface and creates a linked list of three models, namely the appointment calendar, notepad and medical system. State 2: The CSE activates the appointment calendar as follows. CSE displays the three models using presentation interface. Assume the user conditions the appointment calendar. Since the appointment calendar has no object, CSE creates appointment calendar object and sets control flags and control expressions defined at model equal to object, that is UPDATE ADD, SELECT EXPRESSION. The CSE also sets all attributes defined under the model as attributes of appointment calendar object. Now if object has attribute type and selects expression type attribute, it expands attributes using attribute selection expression. In this, 9:30 A.M. has attribute type equal to time and has associated attribute selection expression. CSE executes select expression and creates attributes from 9:00 A.M. to 5:00 P.M. Since DATE has a UNIQUE flag, the CSE sets DATE as an index for the Appointment Calendar. The object now created is as follows:
______________________________________
#OBJECT APPOINTMENT CALENDAR,PRIMITIVE,UPDATE,LEARN
select,INSTANT
(NEXT INSTANT) ›DATE!+=1; (PREV INSTANT) ›DATE!-= 1
DATE,TYPE=d
DATE,TYPE=d,PTYPE=d,TEMP
09:00 A.M.,TYPE=C,LEN=66
Description
Type any information you want to include for this time
slot.
10:00 A.M.,TYPE=C,LEN=66
Description
Type any information you want to include for this time
slot.
11:00 A.M.,TYPE=C,LEN=66
Description
Type any information you want to include for this time
slot.
12:00 P.M.,TYPE=C,LEN=66
Description
Type any information you want to include for this time
slot.
1:00 P.M.,TYPE=C,LEN=66
Description
Type any information you want to include for this time
slot.
2:00 P.M.,TYPE=C,LEN=66
Description
Type any information you want to include for this time
slot.
3:00 P.M.,TYPE=C,LEN=66
Description
Type any information you want to include for this time
slot.
4:00 P.M.,TYPE=C,LEN=66
Description
Type any information you want to include for this time
slot.
5:00 P.M.,TYPE=C,LEN=66
Description
Type any information you want to include for this time
slot.
NOTE,LEN=134,TYPE=C
Description
Type up to two lines of text as notes.
TODO,LEN=134,TYPE=C
Description
Type up to two lines of text for things to do.
#Index, APPOINTMENT CALENDAR,UNIQUE
______________________________________
The CSE activates the appointment calendar and sets active model to appointment calendar and proceeds to state 3. State 3: Now since there is only one object, CSE sets appointment calendar as object and sets next state to state 4. State 4: Since there is only one action associated with action control flags, CSE sets active action to UPDATE ADD and goes to state 5. State 5: CSE sets all values of calendar to null. Because action instant type has action type flag of an active instant, CSE obtains index value date from user to instantlate the appointment book instant. Since there is a select expression, CSE executes select expression and select expression selects next date if event is "next" or "prey". Since event is "process" CSE obtains date from the user. If date was as result of "next" or "prev", CSE will skip the process of obtaining date from the user. In this case date is not set, so CSE obtains the date from the user using presentation interface. Assume user enters date value. CSE obtains the appointment calendar for the specified date. If appointment book for date exists it goes to state 6. Assume appointment book page does not exist. Since calendar has learn flag CSE sets active instant flag to EMPTY and action to ADD and sets next state to 6. This is where CSE differs from traditional programming systems. Since there is only one control flag associated with action ADD, CSE instantiates the appointment calendar via user interface. The user then modifies the appointment and returns an event assuming user selects an event "next". Since action is ADD and instant is EMPTY, CSE adds calendar for specific date using database interface. CSE then proceeds to state 6. Please note that calendar records in the database appear to exist for all dates to user. In reality no data exists unless there is information in the appointment calendar for given date. This is significant because if one needs to use the database to build a calendar using the database management system, one must create empty records for all years. This can waste significant disk space. The action control flag learn makes it possible to create a database record when instant is instantiated and no record exists. According to the invention, a user of the MICS simply writes information models rather than source code or the like. The information model 12 and functions 16 replace the common source code programs used in computer software systems of the prior art. To modify the operation of the program, the user need only change the information model and thus there is no software maintenance in the traditional sense. This approach is therefore radically different from prior art techniques and practices. Thus a designer desiring to take advantage of the present invention builds models as opposed to applications, thereby allowing end users to create their own applications directly from the business model. As set forth above, a complete medical system is implemented using less than about 700 lines of an information model as compared to thousands upon thousands of lines of complex source code. The main processing engine of the MICS is the CSE machine in which each action creates an event, the event changes a state, and the state triggers an action. A model can be terminated during any state and can be restarred at the same state later. According to the invention, whenever a transaction is terminated, which may occur for example when another model is called for processing, the control engine saves the prior model and the state of the transaction. When the other processing is completed, the control engine reenters the previous transactions at the "action" level (as opposed to the instruction level). The control engine is thus reentrant at the action level. In the preferred embodiment, the information model is defined with the assistance of a BNF grammar using an editor. The BNF grammar also facilitates dividing the application into a set of independent actions. The model is converted into information processing objects using a preprocessor or lexical analyzer that is based on the BNF grammar. An application processing system such as MICS may be greatly enhanced by the inclusion of an expected behavior control system (EBCS) for automatically detecting and correcting the behavior of the actions implemented by the application programs where the expected behavior of the application programs is essentially independent of the application processing system. This allows the expected behavior to be modified without effecting the operation of the application processing system. An EBCS may operate in one of two manners. In a first application the EBCS conforms the behavior of the system to an expected behavior of the system defined by the EBCS. In a second application, a particular behavior may be enforced by the EBCS to alter the processing flow of the application processing system in a desired manner. Referring now to FIG. 3, there is illustrated a preferred embodiment of the present invention. The application processing system 30 consists of an action processor 32 for executing application programs by executing one or more actions required by an application program. The execution of these actions generates a particular behavior. With respect to MICS, the action processor will comprise the control system engine and the application programs will consist of information models. An EBCS 34 interfaces with the action processor 32 and an external input/output 36. In most cases, the EBCS 34 executes after each execution of an application "action" which occurs during active instants (State 5) and process instants (State 6) of an application processing system 32 such as the MICS. However in some cases, execution of the EBCS may occur before execution of an action or expression to check for certain conditions affecting enforcement of a particular process flow. With respect to the ECBS the terms "rules", "expressions" and "actions" are synonymous unless otherwise specified. The EBCS 34 comprises an expected behavior function (EBF) 38 for conforming or enforcing processing system behavior to expected behavior rules in response to the resulting behavior of an action initiated by the application program and a correction action function 40 for executing one or more corrective actions to conform or enforce the expected behavior if an expected behavior rule is not met. The expected behavior function 38 and correction action function 40 may be incorporated as separate rules or as a single rule without effecting the overall operation of the present invention. The expected behavior function 38 consists of a set of rules for determining whether or not an expected behavior for an executed application program action has occurred. This rule may either conform the behavior of the system to an expected behavior or enforce the processing flow of the actions in a desired manner. If the conditions set by the rules within the EBF 38 are not met, a correction ID number is returned which the correction action function 40 uses to enable an associated response for executing actions to achieve the expected behavior for the application processing system. The expected behavior rules of the EBF verify specific behavior for actions initiated by the application programs and implement corrective actions for conforming or enforcing the expected behavior of the system when necessary. The expected behavior rules are divided into two groups, missing action rules and invalid action rules. The missing action rules search for specific behavior which should result in response to a particular action. The invalid action rules defect and correct behavior occurring which should not be occurring. A sample of these rules for conforming system behavior are as follows: Missing action rules 1. If missing index key attribute value then execute action "correct specification to assign index key attribute value." 2. If instant contains cross reference and no cross reference is added to the database then execute action "correct specification to create cross reference." Invalid action rules 1. If user instant and no attribute value change by the user and database update occurs the execute action "correct invalid propagation expression." 2. If loop condition in assignment of attribute values then execute action "terminate assignment loop condition." The above described rules are not meant to be limiting, and any number of rules for conforming and correcting the expected behavior of the system may be used. The following example is an application program corresponding to an information model of the MICS system described previously. This information model will be used to demonstrate the EBCS and its functionality.
______________________________________
#MODEL PAYMENT MANAGER
#OBJECT BANK ACCOUNT,ADD,UPDATE,REPORT
ACT ID,UNIQUE,FPROT
ACCOUNT NO
NAME
BALANCE
#OBJECT TRANSACTION,ADD,UPDATE,REPORT,JOURNAL
propagation
(›ACT ID! NEQ "") ›PAYEE! = ›NAME!.
CODE
propagation
(›CODE! IS "ICR") ›REFRENCE! = 999999.
DATE
PAYEE
AMOUNT
propagation
(›AMOUNT<0) ›REFERENCE! = 999999.
REFERENCE
propagation
=›AMOUNT!.E! IS "999999") ›AMOUNT!
ACT ID
propagation
›PAYEE! = ›NAME!.
STATUS
# TRANSACTION JOURNAL,JOURNAL OF TRANSACTION,HIDE
(›AMOUNT! is not "0") ›CTYPE! = ›CODE!.
CTYPE
PAYEE
DATE
AMOUNT
ACT ID
#BALANCE CHECKBOOK, VIEW OF
TRANSACTION,BROWSE,REPORT
select,ALL
(›STATUS! is "0").
activation
(›LAST BALANCE! IS ZERO) ›LAST BALANCE!=›BALANCE!;
= ›AMOUNT!.CE!
propagation
= ›AMOUNT!.
CODE,ENTRY=15
PAYEE
DATE
AMOUNT
LAST BALANCE,ENTRY=1
#INDEX TRANSACTION,ACT ID
______________________________________
The following description illustrates a number of cases wherein the trace for the operation of the EBCS to conform expected behavior can be seen: Case 1: Assume a user has selected the ADD action of the BANK ACCOUNT object. In execution of State 6 by the CSE, the database operation fails because ACT ID index key attribute value is indexed but the value assignment for ACT ID never occurs because the field is protected from data entry by the FPROT attribute flag and there is no propagation expression or "action" to assign to the attribute value. Upon execution of the EBCS, conformance with the EBCS missing action rule 1 is not achieved, and the correction action function executes "correct specification to assign index key attribute value." Here EBCS correction actions of the correction action function can automatically remove the FPROT attribute flag from ACT ID attribute definition of BANK ACCOUNT to correct the problem without having the user modify the information model, or EBCS correction actions can interact with the user through the input/output interface by displaying the attribute definition and asking the user to change the flag or add a propagation expression to correct the problem to enforce the expected behavior. Case 2: In the TRANSACTION object the JOURNAL flag instructs the CSE to activate the JOURNAL object of TRANSACTION after a database operation. Assume that the user has selected the ADD action of TRANSACTION. If the AMOUNT attribute value is not entered by the user, then the CSE fails to create the JOURNAL database record because upon execution of the JOURNAL object, no attribute value is changed because the propagation expression only changes attribute values if AMOUNT is not zero. EBCS conformance missing action rule number 2 is not achieved, and the correction action function executes "correct specification to create cross reference." The correction action can enforce the behavior by automatically adding the MUST FILL flag to the attribute definition AMOUNT of TRANSACTION or EBCS correction actions can interact with the user using input/output interface to ask the user to change the MUST FILL flag or modify the propagation expression of the JOURNAL object to change at least one attribute value. Case 3: Assume that the user has selected the ADD action and the user enters a CODE value equal to ICR. The REFERENCE value then changes to 999999. This causes the AMOUNT value to become negative, which in turn causes the REFERENCE value to change to 999999. This creates a loop condition and conformance with the EBCS invalid rule 2 fails, and the EBCS executes "terminate loop condition". The correction action function can conform the behavior by automatically terminating the loop condition or asking the user to do so via the input/output interface. It is important to note that there is no fault in any processing portion of the information model itself. The fault is in the information model specification. In a traditional software program, the error would be in the program specifications and the process flow and not in the actions executed in response to the program. In addition to conforming the application processing system to a specific behavior, the EBCS may also enforce processing flow of actions defined by the application programs to a selected behavior. This enables the application processing system to operate in a new manner without altering the databases or application programs as they exist. One example of this enforcement of processing flow would be a method for enabling two users to update a database record at the same time as long as the users were working on different attributes of the record. Currently existing systems do not enable two users to update the same database records concurrently. Presently when an application requests use of a database record for updating purposes, the application initiates a READ UPDATE action that reads the entry within the database and locks the record into an UPDATE mode. During the READ UPDATE action, no other user may access the database record. This is due to the fact that the READ UPDATE action initiated by the application program generates a processing flow that only enables one user to access the desired database. A new type of processing flow may be enforced by the EBCS by using a set of enforcement rules similar to the conformance rules discussed previously. The enforcement rules are different from the conformance rules in that they may be executed both before and after the execution of an action. This is due to the fact that the expected behavior for the action may be different depending upon the existing conditions. Assume the following rules are also included within the EBCS: 1. If operation is READ UPDATE, then get record with READ without UPDATE and activate the instant. 2. If action is READ UPDATE, then wait until record is available for READ UPDATE and update database record with attribute values of the instants which have been changed by the user interface or progation expression. Thus when a READ UPDATE action is executed by the application processing system the EBCS rule 1 causes the record to be read without update. This enables more than one user on the network or client/server computing system to simultaneously update the same record without locking the record during an update session. Upon completion of each user's modifications to a record, each user's updates are returned to the database in accordance with rule 2. Rule number 1 is a pre-enforcement rule executed before execution of an action to direct the processing flow in a desired direction without altering the application programs. In this case, the rule initiates only a READ action. Rule number 2 is a post-enforcement rule for enforcing a particular behavior after execution of an action. In this case, the rule reads the database record for UPDATE READ and modifies the record with the changes made by the user. Rules such as this enable multiple users to update a database record as long as different attributes of the database record are being updated. In a normal processing system, whatever changes are last made to the attribute values of a record are the changes that are finally used within the database record. Should a conflict occur between multiple users trying to update the same attribute during READ UPDATE actions, additional rules may be included in the EBCS to enable resolution of the conflict. A rule may be included in the EBCS enforcing that whichever user has entered the largest number of attribute value changes within a specific group gets priority for all attribute value changes for that group. Thus, in the case where a first user updates one attribute in the record of a first patient and five attributes within the record of a second patient, and a second user only updates ten attributes within a record of the second patient, the corrective actions force the changes made by the first user to control and be entered into the first patient's record, and the attributes entered by the second user to control and be entered into the second patient's record. It should be noted from the foregoing discussion that none of the application programs are being altered in any way. All that is altered is the manner in which the process flow of the actions is carried out to enable new system behaviors to be achieved without reprogramming the application programs. It should also be noted that the particular rules discussed for enforcing process flow are merely illustrative and that any number of rules may be used to achieve any desired behavior. It should be appreciated by those skilled in the art that the specific embodiments disclosed above may be readily utilized as a basis for modifying or designing other structures or techniques for carrying out the same purposes of the present invention. It should also be realized by those skilled in the art that such equivalent constructions do not depart from the spirit and scope of the invention as set forth in the appended claims.
|
Same subclass Same class Consider this |
||||||||||