- Email: [email protected]
Specification of information systems operations in INFOMOD
Data & Knowledge North-Holland
Engineering 2 (1987) 177-190
177
Specification of information operations in INFOMOD
systems
D.A. JARDINE Department
of Computing
and Information
Science,
Queen’s
University,
Kingston,
Ontario,
Canada
J.J. van GRIETHUYSEN Philips
International
BV,
Corporate
ISA-TM.%SM,
Eindhoven,
Netherlands
Abstract. A user-friendly language, INFOMOD, intended for information modelling, with forms for specifying manipulation of the contents of information systems and interaction with the environment of an information system are described. These form part of an overall Conceptual Schema Language based on predicate logic. The operations model permits specification of operations, the semantics of messages from the information systems environment, and the coordination of actions on the information systems contents. Keywords. Information
modelling, conceptual schema, logic, specification languages, databases.
1. Introduction INFOMOD’ is an information modelling language based on first-order predicate calculus. It adopts a philosophical viewpoint of naive realism, that there are entities in the real world, and that entities may have attributes, and may be associated with other entities. Associations are themselves entities, and so are any objects about which information can be manipulated in an information system. The class of all entities that are, have been or ever will be is called the universe of discourse of the information system. The purpose of an INFOMOD information model is to define, in a way which is independent of representation and data-structures, the kinds of entities which are in the universe of discourse, and the laws or rules governing their behaviour. The kinds of entities, and what can be said about them, are described in statements which act as the patterns for sentences which form the information system. For example: Pattern:
Employee
(known by Name, lives at Address, works for Department)
.
specifies a pattern for Employee entities, declares predicates known by, lives at, and works for, and entities Employee, Name, Address, and Department. It also,states a rule to the effect that Employee and Name are kinds of entities which are associated by the predicate known by, and similarly for the other two associations. INFOMOD also provides for specification of rules (axioms) of the universe of discourse. All the facilities of predicate logic are available, as well as modal notions to express that certain attributes are required to be known as a condition for information about a specific ‘INFOMOD
is a development of N.V. Philips Gloeilampenfabrieken,
Netherlands.
0169-023X187/%3.50 @ 1987, Elsevier Science Publishers B.V. (North-Holland)
178
D.A.
Jardinc,
J.J.
vnn
Grierhyser~
I Speci/icnrions
in INFOMOD
entity to be inserted into the information system. Dynamic rules are expressible either in terms of time-instants (defined as entities) or in terms of a finite-state machine, e.g. to express sequencing or causality. A previous paper [2] contains an exposition of patterns and rules, with only a brief description of the operations specification, i.e. the specification of how new information is added to the information system, and how it is manipulated and retrieved. This paper discusses the operations specifications in some detail. Only an intuitive discussion is provided, since the formal definition is much too large to be included in this paper. In many current database systems, there is a clear separation of the database from its associated application programs. However, specification of one in the absence of the other can lead to inconsistency, lack of clarity, and errors in the specifications. INFOMOD has been designed so that all computable aspects of an information system can be specified in the same language. These aspects must include message-handling, information manipulation, and application synchronization. However, the details of data structures, programming language peculiarities, and presentation of information should be excluded, so that the specification does not prejudice the implementation. The integration of data dictionary information with language processors is becoming widespread, and is one way of ensuring that an implementation is consistent with definitions of the database. INFOMOD operations models are intended to provide a specification from which data dictionary entries and programs can be built, although this translation is manual at the present time. Most information modelling languages do not handle information operations at all, and those that do are much more limited than INFOMOD in their expressive power. While INFOMOD, being logic-based, shares several constructs (especially selection and the elementary actions) with the relational database languages, it provides message-handling and synchronization primitives, which are not available in those languages. INFOMOD provides a sound theoretical basis for any information system expressible in first-order logic. It is ultimately axiomatic. Standard first-order mathematical logic and its inference rules are part of the underlying basis. This basis is augmented for each information system by declaration of predicates in entity-vectors and by the axioms (rules) of the INFOMOD information model. The semantics of any INFOMOD information model are thus the standard Tarski semantics [5]. An information model provides a precise definition of the information system’s semantic structure that can be read and understood by analysts, designers and end-users who may have no knowledge of the details of implementation. It also provides an unambiguous specification for information system implementation. INFOMOD has been shown in practice to be superior to less formal information system specification methods. Because it is an axiomatic logical language, it can express succinctly and unambiguously any computerizable information system. It makes no appeal to extralinguistic considerations, and nor to any realization or implementation. It therefore allows an abstract specification of an information system. 2. Permissible actions The basic unit of information manipulation is the permissible action. A permissible action is a grouping of elementary or compound actions which, as a unit, transforms a collection of information in the information system into another collection of information, and/or transmits, via messages, information to the environment or to other permissible actions. The notion of ‘permissible’ is that (the contents of) the information system must satisfy all stated rules both before and after the permissible action. Permissible actions are atomic, so
D.A.
Jardine,
J.J.
van Griethuysen
! Specificadorn
in INFOMOD
179
that only the initial and final collection of information need satisfy the rules. Intermediate states, if recognizable at all, need not satisfy the rules, and are not visible outside the permissible action. If a permissible action causes a change to the contents of the information system, such change takes effect only at the completion of the permissible action, and then only if all relevant rules are satisfied. If relevant rules are not met, the information system is unchanged, as if the permissible action had never happened. A permissible action is triggered by a command or quej, which may be thought of as the imperative or interrogative interpretation of a message. A command or query will cause the triggering of an action only if specified preconditions are met. A permissible action may itself issue messages for other permissible actions. Specifications for messages, permissible actions, initial and final states of permissible actions, sequencing and coordination of permissible actions, and rules to authorize manipulation of information are collectively called the information operations specifications. The information operations specifications are the description of the interface between the environment and the information system, consisting of specifications for -the input and output messages to be exchanged between the environment and the information system; -the conditions and results of the permissible actions manipulating or providing the messages; - the sequencing and coordination of the actions; - the authorization rules establishing which users may manipulate which information. The information system operations are triggered by the commands and queries. These may refer to predefined information operation specifications or may include formulation of messages and actions. 3. Message patterns The informational content of a message is described by a Message Pattern, in much the same way as an Entity Pattern describes information system sentences. It specifies the entities and their attributes which will be referenced in a message described by the pattern. Although a Message Pattern must be specified in terms of the (concrete) syntax of INFOMOD, it contains only the abstract syntax of the message itself. The concrete syntax of a message is declared in a suitable External Schema. The Message Pattern may also describe attributes of the message itself, or include other Message Pattern and command specifications. For example, Pattern: New-employee (Date-of-entry , Time-of-entry, Employee (known by Name, Address), Group (known by Name, Kind-of-group)) .
defines a Message Pattern New-employee which can contain the name and address of an employee, and the name and kind of group for a group. In defining a Message Pattern in this way, nothing is said about any ordering of the information within the message. The proper lay-out of the message is considered in the definition of the message format which is part of the specification on the external level rather
180
D.A.
Jardim,
J.J.
van
Griethysot
I Specificariotts
itI INFOMOD
than the conceptual level. However, ordering criteria for the message contents can be specified using a sequence-function definition. For example, if a list of the employees is needed in the alphabetical sequence of their name, the following Message Pattern may be used: Pattern: Employee-list ((in ascending sequence of Employee (known by Name) : {Employee (known by Name , lives at Address)})) .
In the same way descending ordering criteria or combinations sequences can be specified.
of ascending and descending
4. Elementary actions An elementary action manipulates a sentence. Such sentences may be atomic or complex. The elementary actions supported in INFOMOD are Retrieve, Insert, Delete, and Modify. Only Retrieve and Modify will be discussed in detail. 4.1. Retrieve
The Retrieve action selects information about particular attributes of specific entities and makes this available as an outgoing message to the environment. The general format of the Retrieve action specification is [domains-clause] Retrieve: sentence.
Instead of the word Retrieve the words Show or Report may be used, and are preferred by many INFOMOD users. The domains-clause establishes for which entities the sentence will be shown. The general format of such a domains-clause, as described in [2], is For quantification-option entity-variable [entity-selection-expression]
The entity-selection-expression selected. For example,
in the domains-clause specifies which entity or entities are
For the Employee, who known by Salary-number = “12345”, show: Employee known by Name.
The entity-identifier can be specified using a variable-reference, referenced in an input message. Pattern: Input-message (Employee (Salary-number)) . For the Employee, who known by Salary-number = Input-message (Employee (Salary-number)) , show: Employee known by Name.
An ordered list of these employees may be specified, as in
such as an attribute
D.A.
Jardine,
J.J.
van Grierhrtysen
I Specificalions
in INFOMOD
181
For every Employee, who born on Date after “1940-01-01” or works for Department “Sales”, show: Employee-list ((in ascending sequence of Employee (known by Name) : {Employee (known by Name, lives at Address)})).
Information to be shown may involve entities of more than one entity type. By specifying the involved collections of entities in appropriate domains-clauses, information about several groups of entities may be retrieved. For example, For every Department for which count: {Project with responsible Department) > 10 , for every Employee, who born on Date after “1940-01-01” and works for Department, show: Department known by Name and Employee (known by Name, lives at Address).
4.2. Modify The Modify action changes information specification is
about specified entities. The general format of the
[domains-clause] Modify: sentence.
For example: For the Employee, who identified by Salary-number = “12345” , modify: Employee lives at Address = “37, Bondstreet” .
If more than one entity meets the selection criteria in a domains-clause, the specified information of any one or all of them will be changed, depending on the specification of the quantification option. If no domains-clause is specified, the information about every entity indicated by the entity-variable will be changed. If the selection is ambiguous, which entity is affected is indeterminate. The following example sets salary of $3000 for all employees working for the department whose entity-identifier Department known by Name is given in an input-message: Pattern: Salary-change (Department (known by Name)). For every Employee, who works for Department = Salary-change (Department) , modify: Employee earns Salary = “$3000”.
The above specifies the salary changes irrespective of what salary is earned so far by the employee. If one wants to specify the change for only those that earned less so far, it will be as follows: For every Employee, who works for Department = Salary-change (Department) and earns Salary c “$3000” , modify: Employee earns Salary = “$3000”.
182
D.A.
Jardine,
J.J.
van Grietlruysen
I Specificarions
in INFOMOD
5. Actions on collections INFOMOD provides a general way of defining actions to be carried out on (information about) arbitrary collections of entities, by combining quantification and selection expressions in a domains-clause prefixing an action-specification. The following example inserts information about project tasks where the information is contained in an input message defined by Pattern: Project-plan-message (Project (identified by project-number , responsible DEPARTMENT, planned begindate, planned duration) , {Task (identified by task-number, planned begindate, planned duration, allocated to EMPLOYEE in PROJECT)}).
stating a pattern for a message about the project and its tasks. The following insert the specified information:
action will
For the Project = Project-plan-message (Project) , for every Task, which within Project-plan-message ({Task}) insert: Project (identified by project-number, responsible DEPARTMENT, planned begindate, planned duration) = Project-plan-message (Project (identified by project-number , responsible DEPARTMENT, planned begindate, planned duration)) and Task (identified by task-number, planned begindate, planned duration , allocated to EMPLOYEE in PROJECT) = Project-plan-message (Task (identified by task-number, planned begindate, planned duration, allocated to EMPLOYEE in PROJECT)).
6. Specifying permissible actions The specification of a permissible action begins with a name for the permissible action. It may be followed by a list of forma1 parameters. The body of the action specification is a list of action statements and, optionally, an action condition statement. Thus, the genera1 format is action-name [: formal arguments] = {[action condition] action statements}.
D.A.
Jarditw,
J.J.
van Gricthrcyscn
I Speci~cariotrs
in INFOMOD
183
The action specification describes all changes to be made by the permissible action, provided all relevant rules are satisfied. The new state of the information system is therefore considered not to be materialized until after the execution of the permissible action as a unit. If materialization would violate any rule, no changes will take place, and a violation situation will exist. This implies that an implementation must explicitly check the relevant rules to ensure that the information system will remain consistent after the change(s). A permissible action is the specification of (in today’s technology) an application program or program step, and that program must ensure the validity of the change. In future systems, we can expect rules to be enforced by the underlying information system software. If a violation arises, actions such as the issue of a message, may be specified. The if-situation action may be used to test for existence of such situations. Situation indications include: no violation, any violation, unauthorized, unknown. A permissible action may have a guard, which specifies the conditions under which the permissible action may take place. Usually, this takes the form of a guarded command [l]. A permissible action is triggered when the conditions of the guard are met. In its simplest form, the guard specifies the receipt of an appropriate command for the action, or an input message. However, the guard may be more complex, including reference to the state of the information system or to a specified time event. INFOMOD uses the Action Condition statement to specify a guard. Guards are evaluated in parallel, but may be serialized if desired. Several special action conditions are defined, such as: At receipt of command and At receipt of message, and At date or time indication. Internal events, such as the execution of another permissible action or a change in information can also serve as conditions. Conditions may be combined in logical expressions. Two ways exist to pass input parameters to a permissible action: arguments that are part of the command, or messages that are part of the condition. An example of passing arguments is Provide-employees-of department: department-name = {Action-condition: At receipt of command. If count: {EMPLOYEE who employed by DEPARTMENT} = 0 then: Report: message (DEPARTMENT (known by game), “has no known employees”) else: for every EMPLOYEE who employed by DEPARTMENT, which known by Name = Department-name, show: EMPLOYEE (known by Name, lives at Address).}.
In this example, the guard is the action condition At receipt of command.
7. Compound
actions
Actions may be grouped into a compound action, which is considered as a single action. Compound actions act as mace-constructs, and their purpose is similar. There are to reasons for defining compound actions: a set of actions may be needed in more than one place or the action must be explicitly sequenced. Compound actions are specified as a collection of actions enclosed in braces. These braces do not limit the scope of the reference within the compound action. All information within the scope of the permissible action is within the scope of the included compound action. Compound actions may be defined within a permissible action specification or separately. If a compound action is defined inside a permissible action, it is known inside that permissible action only.
184
D.A.
Jardine,
J.J.
van
Griethysetl
I Specificatiotrs
ill INFOMOD
Actions and compound actions can be named. If a compound action is defined outside a permissible action, then it must be named. The name is known globally and may be referenced in any permissible action. A reference to a named compound action is interpreted exactly as if the body of the compound action were copied at the point of reference. 7.1. Parameterized actions
Named actions can be parameterized. As with functions, these parameters are specified as formal arguments in the action specification. A compound action can be used for authorization control and information hiding. Different levels of authorization can be attached to the definition of a compound action than to its use, and the details of the compound action can be hidden from a user of it. In the following example, the enrollment of a new employee, the employees name and address are supplied as parameters, but the salary-number is computed as one more than the maximum element of the class of salary-numbers known to the information system. Whether this is the best rule for assigning salary-numbers is, of course, a matter for decision by the enterprise. Enroll-new-employee: Subject-Employee (known by Name, lives at Address) = insert: Subject-Employee (known by Name, lives at Address, identified by Salary-number = 1 -t max: {Salary-number such that there is an Employee : Employee (identified by Salary-number)}).
This (pre-defined)
action can be applied to a permissible action as follows:
Add-New-Employee. {Action Condition: At receipt of New-Employee. New-Employee (Date-of-entry , Time-of-entry, Employee (known by Name, lives at Address) , Group (Name, Kind-of-Group)) . Employee = New-Employee’ (Employee) . If Employee known then: Report: Violation-Message (Employee (known by Name, lives at Address) , “already registered”) . Enroll-new-employee: Employee (known by Name, lives at Address) . If New-Employee (Group (Kind-of-group = “Staff”)) then: for the Employee, who known by Name and lives at Address, Insert: Employee belongs-to Staff-group which known by Name = New-Employee (Group (Name)). If New-Employee (Group (Kind-of-group = “Department”)) then: for the Employee who known by Name and lives at Address, Insert: Employee works-for Department which known by Name = New-Employee (Group (Name)) ,
D.A.
Jardine,
J.J.
van
Grierhuysetr
I Specifications
in INFOMOD
185
If any violation then: Report Violation-Message (Employee (known by Name, lives at Address) , “No Registration Possible”).} . 7.2. Ordered compound
actions
Within an action specification, the written order of statements has no significance. The action is a definition of what the result will be, given the state of the information system, the command parameters and the contents of input messages. If it is necessary to specify the order in which elementary or compound actions are to occur, an ordered compound action must be used. Such a sequence is delineated by angle brackets (0). Such cases will be found, in particular, in CAD-CAM systems, for instance.
8. Message handling
Two ways of handling messages are considered: input and output of a permissible action. The input of a message is specifed as the actual argument of a permissible action, or as part of an action condition. These were dealt with previously in this paper. An input message normally originates in the environment. However, INFOMOD allows an input message to originate from a permissible action. A permissible action may receive messages originating from itself. The output of a message is specified as a result of a Retrieve action. The output message may contain information about attributes of entities, or may be information reporting situations found in the information system or the results of permissible actions. An output message is considered to be issued only at the conclusion of the permissible action that generated it, and is issued only if the results of the permissible action obey all the stated rules of the information model. A pattern and a typical output specification are Pattern: Employee-address (Name, Address). For Employee that manages Department “Sales” Report: Employee-address (Name where Employee known by Name, Address where Employee lives at Address).
(Other examples have been shown in passing.) The reporting of a message may be specified anywhere in the permissible action, but is issued only at the action’s conclusion, unless it is a part of an ordered compound action (q-v.). Messages may be specified to exist forever in the information system. A permissible action may need to examine ‘old’ messages, as for instance, in specifying damage assessment and repair routines. Since messages are global and may be eternal, messages that have already been received by a given permissible action may be made distinguishable from those that have not. This implies (in an implementation) tagging messages to show whether they have been received by the permissible action(s) for which the messages are specified as Input. For this purpose appropriate message attributes may be specified, such as date-of-entry and time-of-entry. Such messages should be explicitly inserted by the permissible action for which they are input or output. For example,
186
D.A.
Jnrdirle,
J.J.
vnrr Grierhuyscser~
/ Specificntiorw
ia INFOMOD
Pattern: ADDRESS-MODIFICATION (Date-of-entry, Time-of-entry, EMPLOYEE (known by Name, Old-address, New-address)) . Change-employee-address = {Action-condition: At receipt of ADDRESS-MODIFICATION. Insert: ADDRESS-MODIFICATION (Date-of-entry = today, Time-of-entry = now, EMPLOYEE (known by Name, Old-address, New-address)) . For the EMPLOYEE who known by Name = ADDRESS-MODIFICATION (EMPLOYEE (known by Name)), and lives at Address = ADDRESS-MODIFICATION (EMPLOYEE (Old-address)) modify: EMPLOYEE lives at Address = ADDRESS-MODIFICATION (EMPLOYEE (New-address)) . If EMPLOYEE unknown then: Report: message (EMPLOYEE (known by Name), “is not known”).} .
(Today and now are XNFOMOD above example, the insertion.)
9. Coordination
constants indicating
the exact date and time of, in the
of permissible actions
Communication between environment and information system occurs by messages. Communication inside the information system may take place by messages among permissible actions, but more usually takes place through the contents of the information system fulfilling guards to permissible actions. Since output messages are materialized only at the end of the permissible action, it follows that communicating actions are atomic with respect to message passing. A suitable form of guard on the permissible actions involved can be used to ensure that messages are handled in an order appropriate to the semantics of the communicating actions. It is expected that communicating permissible actions will use messages peculiar to them only, but this is not a requirement. The use of broadcast messages for synchronization and communication among processes that do not share memory has been studied in an operating systems context by [4], which demonstrates how to provide distributed semaphores and CSP-like synchronization based on broadcast messages. Reliable synchronization depends on suitable time-stamping of messages [3], and monotonicity of predicates with respect to time and queue length. These can be satisfied by INFOMOD constructs or by the underlying DBMS or message handling system. Synchronization of permissible actions by the contents of the information system is merely a variant of the readers and writers problem using CSP-like guarded commands. Waiting conditions may be specified in an action condition. A waiting period (a local clock) is started when the first elementary or atomic condition in the action condition is
D.A. Jardine, J.J. van Griethysen
I Specificariotu in INFOMOD
187
satisfied. Minimum and maximum times may be specified, as well as counting the number of events. Thus, a guard may be gradually satisfied over a period to time. If satisfaction of the guard depends both on the state of the information system and on the receipt of messages, the guard uses the most recent state of the information system before permitting the permissible action to continue. For example, the following condition requires two messages, one containing new-employee information and another authorizing the hiring. These two messages must be received within one day of each other to trigger the remainder of the permissible action. If the waiting period is exceeded, the receipt of either message will have no effect. Action-condition : At receipt of New-employee (Employee (known by Name)) and receipt of Authorization (Employee (known by Name)) and New-employee (Employee) = Authorization (Employee) and waiting at most 1 day.
10. Authorization Authorization rules are an important part of information operations specifications. FOMOD allows for a rich variety of these, and some examples are presented. Employees may be authorized to retrieve all information about themselves only:
IN-
Employee checked by Password authorized to Retrieve Employee (all attributes).
A manager of a department department:
may retrieve specific information
about all employees of the
For every Manager who manages Department which employs Employee : Manager checked by Password authorized to Retrieve Employee (known by Name, lives at Address, identified by Salary-number, employed by Department, reports to Manager, works for Department, allocated Task in Project).
It is common to require multiple simultaneous authorization, as with two locks on a vault or two signatures on a cheque. For example, Manager Johnson and Manager Smith are authorized jointly to change the salary budget of the Sales Department: For Department “Sales” : Manager “Johnson” checked by Password and Manager “Smith” checked by Password authorized to Modify Department (allotted Salary-budget) .
188
D.A.
Jnrdirte.
J. J. vm
Grierhuysen
I Specificdons
Employees assigned to a project may retrieve all information time the project is in progress:
in INFOMOD
about the project during the
For every Employee with allocated Task in Project: Employee checked by Password authorized to Retrieve Project (all attributes) during Period since Date# such that Project Actual-begin-date = Date# until Date## such that Project Actual-end-date = Date##
Every authorized employee who is not manager of a department may retrieve information about only the average salary-amount of the department and then only if the department employs more than ten employees: For every Department for which count: {Employee who works for Department} > 10, for every Employee who works for Department : Employee checked by Password authorized to Retrieve Department (Average-salary-amount) .
In the above example, it is assumed that a manager is an employee and, therefore, is authorized to retrieve the salary-amount in both cases. As a last example, the case of authorizing change in the specifications themselves: authorization specifications may be accepted only the Information Controller provided he can meet a special permissible action called Information-controller-check: For every Authorization-specification within Information-model Personnel-management : Information-Controller (identified by name = “Smith”, lives at Address = I‘. . . . . . .“) checked by Information-controller-check authorized to {insert Authorization-specification (all attributes) , delete Authorization-specification (all attributes) , modify Authorization-specification (all attributes)} .
11. Commands and queries Permissible actions are triggered by submitting the appropriate command. Such command may be specified in the INFOMOD language itself. The general format of a command is as follows: action-name [: actual argumentsj[issuing-user-indication] !
the ‘!’ being the command terminator. However, every elementary, compound or permissible action-specification or message terminated by the command terminator instead of the period serves as a command. Some examples are: Provide-employee-address: “John” !
D.A.
Jardine,
J.J.
van
Griethuysen
I Specifications
in INFOMOD
189
For the Employee known by Salary-number = “12345” , show: Employee known by Name ! Subject-Employee (Name = “John”) ! Commands can also be used to actually insert rule-sentences in an information in the information system. Observe the difference in the next two examples:
model kept
For every Employee, who works for Department “Sales” insert: Employee speaks Language = “English” !
inserts, for every relevant employee,
the fact that he speaks English.
For one Rule Insert: Rule = ‘For every Employee, which works for Department “Sales” : Employee speaks Language = “English” ’ !
inserts a rule that every involved employee speaks English. Any sentence that is terminated by a question-mark ‘?’ is considered to be a query. The response of the information system is defined as follows: - The result of a query specification is ‘true’ if the sentence is in the information system or is deducible from information in the information system. -The result of a query specification is ‘false’ if the negation of the sentence is in the information system or is deducible from information in the information system. - The result of a query specification is ‘possible’ if the sentence is subject to a ‘possible’ rule or is deducible only by also considering at least one ‘possible’ rule. - If the sentence contains a string-mask for any entity, the result of the query is the sentence with an appropriate string replacing the string-mask. -The result of a query specification is ‘unknown’ if the sentence is not ‘true’, ‘false’, ‘possible’ or does not provide a known string for all string-masks. Some examples are For every Employee : Employee speaks Language = “English” ?
is ‘true’ only if all employees known to the system speak English. Employee “John” lives at Address = ? . . ?, “Bondstreet” ?
will provide the correct house number, if known. Count: {Employee} = ? . . ? ?
will produce the number of employees known in the information
system.
12. Summary
INFOMOD is a fully specified Conceptual Schema and Information Modelling Language. This paper has described the operations specifications possible in INFOMOD. These
190
D.A. Jnrdtirc, J. 1. vnrt Grietlrrtysett I Specificntiotts itt INFOMOD
specifications have been in practical use for the past two years, and have been found to be easy to learn and use, and to provide unambiguous specifications to implementers. Acknowledgment The authors gratefully acknowledge the kind permission of Philips International BV to publish this paper, the financial support (to DAJ) by the Natural Sciences and Engineering Research Council of Canada, and the comments and suggestions of the editor and the referees. References [l] C.A.R. Hoare. Communicating sequential processes, Cottttn. ACM 21 (1978) 666-677. [2] D.A. Jardine and J.J. van Griethuysen, A logic-based information modelling language, Darn md Knowledge Ettgrg. 2 (1987) 59-81. [3] L. Lamport, Time, clocks, and the ordering of events in a distributed system, Cottm. ACM 2 (1978) 558-565. [4] F.B. Schneider, Synchronization in distributed programs, ACM Trms. Progmttmittg Lnrtgrtnges and Sysretns 4 (1982) 125-148. [S] A. Tarski, Der Wahrheitsbegriff in den formalisieren Sprachen, Studin Philos. 1 (1936) 261-405. Translated as: The concept of truth in formalized languages, in: A Tarski, Logic, Setttnttrics, Metntttnthetttntics (Clarendon Press, Oxford, 1983).
Engineering 2 (1987) 177-190
177
Specification of information operations in INFOMOD
systems
D.A. JARDINE Department
of Computing
and Information
Science,
Queen’s
University,
Kingston,
Ontario,
Canada
J.J. van GRIETHUYSEN Philips
International
BV,
Corporate
ISA-TM.%SM,
Eindhoven,
Netherlands
Abstract. A user-friendly language, INFOMOD, intended for information modelling, with forms for specifying manipulation of the contents of information systems and interaction with the environment of an information system are described. These form part of an overall Conceptual Schema Language based on predicate logic. The operations model permits specification of operations, the semantics of messages from the information systems environment, and the coordination of actions on the information systems contents. Keywords. Information
modelling, conceptual schema, logic, specification languages, databases.
1. Introduction INFOMOD’ is an information modelling language based on first-order predicate calculus. It adopts a philosophical viewpoint of naive realism, that there are entities in the real world, and that entities may have attributes, and may be associated with other entities. Associations are themselves entities, and so are any objects about which information can be manipulated in an information system. The class of all entities that are, have been or ever will be is called the universe of discourse of the information system. The purpose of an INFOMOD information model is to define, in a way which is independent of representation and data-structures, the kinds of entities which are in the universe of discourse, and the laws or rules governing their behaviour. The kinds of entities, and what can be said about them, are described in statements which act as the patterns for sentences which form the information system. For example: Pattern:
Employee
(known by Name, lives at Address, works for Department)
.
specifies a pattern for Employee entities, declares predicates known by, lives at, and works for, and entities Employee, Name, Address, and Department. It also,states a rule to the effect that Employee and Name are kinds of entities which are associated by the predicate known by, and similarly for the other two associations. INFOMOD also provides for specification of rules (axioms) of the universe of discourse. All the facilities of predicate logic are available, as well as modal notions to express that certain attributes are required to be known as a condition for information about a specific ‘INFOMOD
is a development of N.V. Philips Gloeilampenfabrieken,
Netherlands.
0169-023X187/%3.50 @ 1987, Elsevier Science Publishers B.V. (North-Holland)
178
D.A.
Jardinc,
J.J.
vnn
Grierhyser~
I Speci/icnrions
in INFOMOD
entity to be inserted into the information system. Dynamic rules are expressible either in terms of time-instants (defined as entities) or in terms of a finite-state machine, e.g. to express sequencing or causality. A previous paper [2] contains an exposition of patterns and rules, with only a brief description of the operations specification, i.e. the specification of how new information is added to the information system, and how it is manipulated and retrieved. This paper discusses the operations specifications in some detail. Only an intuitive discussion is provided, since the formal definition is much too large to be included in this paper. In many current database systems, there is a clear separation of the database from its associated application programs. However, specification of one in the absence of the other can lead to inconsistency, lack of clarity, and errors in the specifications. INFOMOD has been designed so that all computable aspects of an information system can be specified in the same language. These aspects must include message-handling, information manipulation, and application synchronization. However, the details of data structures, programming language peculiarities, and presentation of information should be excluded, so that the specification does not prejudice the implementation. The integration of data dictionary information with language processors is becoming widespread, and is one way of ensuring that an implementation is consistent with definitions of the database. INFOMOD operations models are intended to provide a specification from which data dictionary entries and programs can be built, although this translation is manual at the present time. Most information modelling languages do not handle information operations at all, and those that do are much more limited than INFOMOD in their expressive power. While INFOMOD, being logic-based, shares several constructs (especially selection and the elementary actions) with the relational database languages, it provides message-handling and synchronization primitives, which are not available in those languages. INFOMOD provides a sound theoretical basis for any information system expressible in first-order logic. It is ultimately axiomatic. Standard first-order mathematical logic and its inference rules are part of the underlying basis. This basis is augmented for each information system by declaration of predicates in entity-vectors and by the axioms (rules) of the INFOMOD information model. The semantics of any INFOMOD information model are thus the standard Tarski semantics [5]. An information model provides a precise definition of the information system’s semantic structure that can be read and understood by analysts, designers and end-users who may have no knowledge of the details of implementation. It also provides an unambiguous specification for information system implementation. INFOMOD has been shown in practice to be superior to less formal information system specification methods. Because it is an axiomatic logical language, it can express succinctly and unambiguously any computerizable information system. It makes no appeal to extralinguistic considerations, and nor to any realization or implementation. It therefore allows an abstract specification of an information system. 2. Permissible actions The basic unit of information manipulation is the permissible action. A permissible action is a grouping of elementary or compound actions which, as a unit, transforms a collection of information in the information system into another collection of information, and/or transmits, via messages, information to the environment or to other permissible actions. The notion of ‘permissible’ is that (the contents of) the information system must satisfy all stated rules both before and after the permissible action. Permissible actions are atomic, so
D.A.
Jardine,
J.J.
van Griethuysen
! Specificadorn
in INFOMOD
179
that only the initial and final collection of information need satisfy the rules. Intermediate states, if recognizable at all, need not satisfy the rules, and are not visible outside the permissible action. If a permissible action causes a change to the contents of the information system, such change takes effect only at the completion of the permissible action, and then only if all relevant rules are satisfied. If relevant rules are not met, the information system is unchanged, as if the permissible action had never happened. A permissible action is triggered by a command or quej, which may be thought of as the imperative or interrogative interpretation of a message. A command or query will cause the triggering of an action only if specified preconditions are met. A permissible action may itself issue messages for other permissible actions. Specifications for messages, permissible actions, initial and final states of permissible actions, sequencing and coordination of permissible actions, and rules to authorize manipulation of information are collectively called the information operations specifications. The information operations specifications are the description of the interface between the environment and the information system, consisting of specifications for -the input and output messages to be exchanged between the environment and the information system; -the conditions and results of the permissible actions manipulating or providing the messages; - the sequencing and coordination of the actions; - the authorization rules establishing which users may manipulate which information. The information system operations are triggered by the commands and queries. These may refer to predefined information operation specifications or may include formulation of messages and actions. 3. Message patterns The informational content of a message is described by a Message Pattern, in much the same way as an Entity Pattern describes information system sentences. It specifies the entities and their attributes which will be referenced in a message described by the pattern. Although a Message Pattern must be specified in terms of the (concrete) syntax of INFOMOD, it contains only the abstract syntax of the message itself. The concrete syntax of a message is declared in a suitable External Schema. The Message Pattern may also describe attributes of the message itself, or include other Message Pattern and command specifications. For example, Pattern: New-employee (Date-of-entry , Time-of-entry, Employee (known by Name, Address), Group (known by Name, Kind-of-group)) .
defines a Message Pattern New-employee which can contain the name and address of an employee, and the name and kind of group for a group. In defining a Message Pattern in this way, nothing is said about any ordering of the information within the message. The proper lay-out of the message is considered in the definition of the message format which is part of the specification on the external level rather
180
D.A.
Jardim,
J.J.
van
Griethysot
I Specificariotts
itI INFOMOD
than the conceptual level. However, ordering criteria for the message contents can be specified using a sequence-function definition. For example, if a list of the employees is needed in the alphabetical sequence of their name, the following Message Pattern may be used: Pattern: Employee-list ((in ascending sequence of Employee (known by Name) : {Employee (known by Name , lives at Address)})) .
In the same way descending ordering criteria or combinations sequences can be specified.
of ascending and descending
4. Elementary actions An elementary action manipulates a sentence. Such sentences may be atomic or complex. The elementary actions supported in INFOMOD are Retrieve, Insert, Delete, and Modify. Only Retrieve and Modify will be discussed in detail. 4.1. Retrieve
The Retrieve action selects information about particular attributes of specific entities and makes this available as an outgoing message to the environment. The general format of the Retrieve action specification is [domains-clause] Retrieve: sentence.
Instead of the word Retrieve the words Show or Report may be used, and are preferred by many INFOMOD users. The domains-clause establishes for which entities the sentence will be shown. The general format of such a domains-clause, as described in [2], is For quantification-option entity-variable [entity-selection-expression]
The entity-selection-expression selected. For example,
in the domains-clause specifies which entity or entities are
For the Employee, who known by Salary-number = “12345”, show: Employee known by Name.
The entity-identifier can be specified using a variable-reference, referenced in an input message. Pattern: Input-message (Employee (Salary-number)) . For the Employee, who known by Salary-number = Input-message (Employee (Salary-number)) , show: Employee known by Name.
An ordered list of these employees may be specified, as in
such as an attribute
D.A.
Jardine,
J.J.
van Grierhrtysen
I Specificalions
in INFOMOD
181
For every Employee, who born on Date after “1940-01-01” or works for Department “Sales”, show: Employee-list ((in ascending sequence of Employee (known by Name) : {Employee (known by Name, lives at Address)})).
Information to be shown may involve entities of more than one entity type. By specifying the involved collections of entities in appropriate domains-clauses, information about several groups of entities may be retrieved. For example, For every Department for which count: {Project with responsible Department) > 10 , for every Employee, who born on Date after “1940-01-01” and works for Department, show: Department known by Name and Employee (known by Name, lives at Address).
4.2. Modify The Modify action changes information specification is
about specified entities. The general format of the
[domains-clause] Modify: sentence.
For example: For the Employee, who identified by Salary-number = “12345” , modify: Employee lives at Address = “37, Bondstreet” .
If more than one entity meets the selection criteria in a domains-clause, the specified information of any one or all of them will be changed, depending on the specification of the quantification option. If no domains-clause is specified, the information about every entity indicated by the entity-variable will be changed. If the selection is ambiguous, which entity is affected is indeterminate. The following example sets salary of $3000 for all employees working for the department whose entity-identifier Department known by Name is given in an input-message: Pattern: Salary-change (Department (known by Name)). For every Employee, who works for Department = Salary-change (Department) , modify: Employee earns Salary = “$3000”.
The above specifies the salary changes irrespective of what salary is earned so far by the employee. If one wants to specify the change for only those that earned less so far, it will be as follows: For every Employee, who works for Department = Salary-change (Department) and earns Salary c “$3000” , modify: Employee earns Salary = “$3000”.
182
D.A.
Jardine,
J.J.
van Grietlruysen
I Specificarions
in INFOMOD
5. Actions on collections INFOMOD provides a general way of defining actions to be carried out on (information about) arbitrary collections of entities, by combining quantification and selection expressions in a domains-clause prefixing an action-specification. The following example inserts information about project tasks where the information is contained in an input message defined by Pattern: Project-plan-message (Project (identified by project-number , responsible DEPARTMENT, planned begindate, planned duration) , {Task (identified by task-number, planned begindate, planned duration, allocated to EMPLOYEE in PROJECT)}).
stating a pattern for a message about the project and its tasks. The following insert the specified information:
action will
For the Project = Project-plan-message (Project) , for every Task, which within Project-plan-message ({Task}) insert: Project (identified by project-number, responsible DEPARTMENT, planned begindate, planned duration) = Project-plan-message (Project (identified by project-number , responsible DEPARTMENT, planned begindate, planned duration)) and Task (identified by task-number, planned begindate, planned duration , allocated to EMPLOYEE in PROJECT) = Project-plan-message (Task (identified by task-number, planned begindate, planned duration, allocated to EMPLOYEE in PROJECT)).
6. Specifying permissible actions The specification of a permissible action begins with a name for the permissible action. It may be followed by a list of forma1 parameters. The body of the action specification is a list of action statements and, optionally, an action condition statement. Thus, the genera1 format is action-name [: formal arguments] = {[action condition] action statements}.
D.A.
Jarditw,
J.J.
van Gricthrcyscn
I Speci~cariotrs
in INFOMOD
183
The action specification describes all changes to be made by the permissible action, provided all relevant rules are satisfied. The new state of the information system is therefore considered not to be materialized until after the execution of the permissible action as a unit. If materialization would violate any rule, no changes will take place, and a violation situation will exist. This implies that an implementation must explicitly check the relevant rules to ensure that the information system will remain consistent after the change(s). A permissible action is the specification of (in today’s technology) an application program or program step, and that program must ensure the validity of the change. In future systems, we can expect rules to be enforced by the underlying information system software. If a violation arises, actions such as the issue of a message, may be specified. The if-situation action may be used to test for existence of such situations. Situation indications include: no violation, any violation, unauthorized, unknown. A permissible action may have a guard, which specifies the conditions under which the permissible action may take place. Usually, this takes the form of a guarded command [l]. A permissible action is triggered when the conditions of the guard are met. In its simplest form, the guard specifies the receipt of an appropriate command for the action, or an input message. However, the guard may be more complex, including reference to the state of the information system or to a specified time event. INFOMOD uses the Action Condition statement to specify a guard. Guards are evaluated in parallel, but may be serialized if desired. Several special action conditions are defined, such as: At receipt of command and At receipt of message, and At date or time indication. Internal events, such as the execution of another permissible action or a change in information can also serve as conditions. Conditions may be combined in logical expressions. Two ways exist to pass input parameters to a permissible action: arguments that are part of the command, or messages that are part of the condition. An example of passing arguments is Provide-employees-of department: department-name = {Action-condition: At receipt of command. If count: {EMPLOYEE who employed by DEPARTMENT} = 0 then: Report: message (DEPARTMENT (known by game), “has no known employees”) else: for every EMPLOYEE who employed by DEPARTMENT, which known by Name = Department-name, show: EMPLOYEE (known by Name, lives at Address).}.
In this example, the guard is the action condition At receipt of command.
7. Compound
actions
Actions may be grouped into a compound action, which is considered as a single action. Compound actions act as mace-constructs, and their purpose is similar. There are to reasons for defining compound actions: a set of actions may be needed in more than one place or the action must be explicitly sequenced. Compound actions are specified as a collection of actions enclosed in braces. These braces do not limit the scope of the reference within the compound action. All information within the scope of the permissible action is within the scope of the included compound action. Compound actions may be defined within a permissible action specification or separately. If a compound action is defined inside a permissible action, it is known inside that permissible action only.
184
D.A.
Jardine,
J.J.
van
Griethysetl
I Specificatiotrs
ill INFOMOD
Actions and compound actions can be named. If a compound action is defined outside a permissible action, then it must be named. The name is known globally and may be referenced in any permissible action. A reference to a named compound action is interpreted exactly as if the body of the compound action were copied at the point of reference. 7.1. Parameterized actions
Named actions can be parameterized. As with functions, these parameters are specified as formal arguments in the action specification. A compound action can be used for authorization control and information hiding. Different levels of authorization can be attached to the definition of a compound action than to its use, and the details of the compound action can be hidden from a user of it. In the following example, the enrollment of a new employee, the employees name and address are supplied as parameters, but the salary-number is computed as one more than the maximum element of the class of salary-numbers known to the information system. Whether this is the best rule for assigning salary-numbers is, of course, a matter for decision by the enterprise. Enroll-new-employee: Subject-Employee (known by Name, lives at Address) = insert: Subject-Employee (known by Name, lives at Address, identified by Salary-number = 1 -t max: {Salary-number such that there is an Employee : Employee (identified by Salary-number)}).
This (pre-defined)
action can be applied to a permissible action as follows:
Add-New-Employee. {Action Condition: At receipt of New-Employee. New-Employee (Date-of-entry , Time-of-entry, Employee (known by Name, lives at Address) , Group (Name, Kind-of-Group)) . Employee = New-Employee’ (Employee) . If Employee known then: Report: Violation-Message (Employee (known by Name, lives at Address) , “already registered”) . Enroll-new-employee: Employee (known by Name, lives at Address) . If New-Employee (Group (Kind-of-group = “Staff”)) then: for the Employee, who known by Name and lives at Address, Insert: Employee belongs-to Staff-group which known by Name = New-Employee (Group (Name)). If New-Employee (Group (Kind-of-group = “Department”)) then: for the Employee who known by Name and lives at Address, Insert: Employee works-for Department which known by Name = New-Employee (Group (Name)) ,
D.A.
Jardine,
J.J.
van
Grierhuysetr
I Specifications
in INFOMOD
185
If any violation then: Report Violation-Message (Employee (known by Name, lives at Address) , “No Registration Possible”).} . 7.2. Ordered compound
actions
Within an action specification, the written order of statements has no significance. The action is a definition of what the result will be, given the state of the information system, the command parameters and the contents of input messages. If it is necessary to specify the order in which elementary or compound actions are to occur, an ordered compound action must be used. Such a sequence is delineated by angle brackets (0). Such cases will be found, in particular, in CAD-CAM systems, for instance.
8. Message handling
Two ways of handling messages are considered: input and output of a permissible action. The input of a message is specifed as the actual argument of a permissible action, or as part of an action condition. These were dealt with previously in this paper. An input message normally originates in the environment. However, INFOMOD allows an input message to originate from a permissible action. A permissible action may receive messages originating from itself. The output of a message is specified as a result of a Retrieve action. The output message may contain information about attributes of entities, or may be information reporting situations found in the information system or the results of permissible actions. An output message is considered to be issued only at the conclusion of the permissible action that generated it, and is issued only if the results of the permissible action obey all the stated rules of the information model. A pattern and a typical output specification are Pattern: Employee-address (Name, Address). For Employee that manages Department “Sales” Report: Employee-address (Name where Employee known by Name, Address where Employee lives at Address).
(Other examples have been shown in passing.) The reporting of a message may be specified anywhere in the permissible action, but is issued only at the action’s conclusion, unless it is a part of an ordered compound action (q-v.). Messages may be specified to exist forever in the information system. A permissible action may need to examine ‘old’ messages, as for instance, in specifying damage assessment and repair routines. Since messages are global and may be eternal, messages that have already been received by a given permissible action may be made distinguishable from those that have not. This implies (in an implementation) tagging messages to show whether they have been received by the permissible action(s) for which the messages are specified as Input. For this purpose appropriate message attributes may be specified, such as date-of-entry and time-of-entry. Such messages should be explicitly inserted by the permissible action for which they are input or output. For example,
186
D.A.
Jnrdirle,
J.J.
vnrr Grierhuyscser~
/ Specificntiorw
ia INFOMOD
Pattern: ADDRESS-MODIFICATION (Date-of-entry, Time-of-entry, EMPLOYEE (known by Name, Old-address, New-address)) . Change-employee-address = {Action-condition: At receipt of ADDRESS-MODIFICATION. Insert: ADDRESS-MODIFICATION (Date-of-entry = today, Time-of-entry = now, EMPLOYEE (known by Name, Old-address, New-address)) . For the EMPLOYEE who known by Name = ADDRESS-MODIFICATION (EMPLOYEE (known by Name)), and lives at Address = ADDRESS-MODIFICATION (EMPLOYEE (Old-address)) modify: EMPLOYEE lives at Address = ADDRESS-MODIFICATION (EMPLOYEE (New-address)) . If EMPLOYEE unknown then: Report: message (EMPLOYEE (known by Name), “is not known”).} .
(Today and now are XNFOMOD above example, the insertion.)
9. Coordination
constants indicating
the exact date and time of, in the
of permissible actions
Communication between environment and information system occurs by messages. Communication inside the information system may take place by messages among permissible actions, but more usually takes place through the contents of the information system fulfilling guards to permissible actions. Since output messages are materialized only at the end of the permissible action, it follows that communicating actions are atomic with respect to message passing. A suitable form of guard on the permissible actions involved can be used to ensure that messages are handled in an order appropriate to the semantics of the communicating actions. It is expected that communicating permissible actions will use messages peculiar to them only, but this is not a requirement. The use of broadcast messages for synchronization and communication among processes that do not share memory has been studied in an operating systems context by [4], which demonstrates how to provide distributed semaphores and CSP-like synchronization based on broadcast messages. Reliable synchronization depends on suitable time-stamping of messages [3], and monotonicity of predicates with respect to time and queue length. These can be satisfied by INFOMOD constructs or by the underlying DBMS or message handling system. Synchronization of permissible actions by the contents of the information system is merely a variant of the readers and writers problem using CSP-like guarded commands. Waiting conditions may be specified in an action condition. A waiting period (a local clock) is started when the first elementary or atomic condition in the action condition is
D.A. Jardine, J.J. van Griethysen
I Specificariotu in INFOMOD
187
satisfied. Minimum and maximum times may be specified, as well as counting the number of events. Thus, a guard may be gradually satisfied over a period to time. If satisfaction of the guard depends both on the state of the information system and on the receipt of messages, the guard uses the most recent state of the information system before permitting the permissible action to continue. For example, the following condition requires two messages, one containing new-employee information and another authorizing the hiring. These two messages must be received within one day of each other to trigger the remainder of the permissible action. If the waiting period is exceeded, the receipt of either message will have no effect. Action-condition : At receipt of New-employee (Employee (known by Name)) and receipt of Authorization (Employee (known by Name)) and New-employee (Employee) = Authorization (Employee) and waiting at most 1 day.
10. Authorization Authorization rules are an important part of information operations specifications. FOMOD allows for a rich variety of these, and some examples are presented. Employees may be authorized to retrieve all information about themselves only:
IN-
Employee checked by Password authorized to Retrieve Employee (all attributes).
A manager of a department department:
may retrieve specific information
about all employees of the
For every Manager who manages Department which employs Employee : Manager checked by Password authorized to Retrieve Employee (known by Name, lives at Address, identified by Salary-number, employed by Department, reports to Manager, works for Department, allocated Task in Project).
It is common to require multiple simultaneous authorization, as with two locks on a vault or two signatures on a cheque. For example, Manager Johnson and Manager Smith are authorized jointly to change the salary budget of the Sales Department: For Department “Sales” : Manager “Johnson” checked by Password and Manager “Smith” checked by Password authorized to Modify Department (allotted Salary-budget) .
188
D.A.
Jnrdirte.
J. J. vm
Grierhuysen
I Specificdons
Employees assigned to a project may retrieve all information time the project is in progress:
in INFOMOD
about the project during the
For every Employee with allocated Task in Project: Employee checked by Password authorized to Retrieve Project (all attributes) during Period since Date# such that Project Actual-begin-date = Date# until Date## such that Project Actual-end-date = Date##
Every authorized employee who is not manager of a department may retrieve information about only the average salary-amount of the department and then only if the department employs more than ten employees: For every Department for which count: {Employee who works for Department} > 10, for every Employee who works for Department : Employee checked by Password authorized to Retrieve Department (Average-salary-amount) .
In the above example, it is assumed that a manager is an employee and, therefore, is authorized to retrieve the salary-amount in both cases. As a last example, the case of authorizing change in the specifications themselves: authorization specifications may be accepted only the Information Controller provided he can meet a special permissible action called Information-controller-check: For every Authorization-specification within Information-model Personnel-management : Information-Controller (identified by name = “Smith”, lives at Address = I‘. . . . . . .“) checked by Information-controller-check authorized to {insert Authorization-specification (all attributes) , delete Authorization-specification (all attributes) , modify Authorization-specification (all attributes)} .
11. Commands and queries Permissible actions are triggered by submitting the appropriate command. Such command may be specified in the INFOMOD language itself. The general format of a command is as follows: action-name [: actual argumentsj[issuing-user-indication] !
the ‘!’ being the command terminator. However, every elementary, compound or permissible action-specification or message terminated by the command terminator instead of the period serves as a command. Some examples are: Provide-employee-address: “John” !
D.A.
Jardine,
J.J.
van
Griethuysen
I Specifications
in INFOMOD
189
For the Employee known by Salary-number = “12345” , show: Employee known by Name ! Subject-Employee (Name = “John”) ! Commands can also be used to actually insert rule-sentences in an information in the information system. Observe the difference in the next two examples:
model kept
For every Employee, who works for Department “Sales” insert: Employee speaks Language = “English” !
inserts, for every relevant employee,
the fact that he speaks English.
For one Rule Insert: Rule = ‘For every Employee, which works for Department “Sales” : Employee speaks Language = “English” ’ !
inserts a rule that every involved employee speaks English. Any sentence that is terminated by a question-mark ‘?’ is considered to be a query. The response of the information system is defined as follows: - The result of a query specification is ‘true’ if the sentence is in the information system or is deducible from information in the information system. -The result of a query specification is ‘false’ if the negation of the sentence is in the information system or is deducible from information in the information system. - The result of a query specification is ‘possible’ if the sentence is subject to a ‘possible’ rule or is deducible only by also considering at least one ‘possible’ rule. - If the sentence contains a string-mask for any entity, the result of the query is the sentence with an appropriate string replacing the string-mask. -The result of a query specification is ‘unknown’ if the sentence is not ‘true’, ‘false’, ‘possible’ or does not provide a known string for all string-masks. Some examples are For every Employee : Employee speaks Language = “English” ?
is ‘true’ only if all employees known to the system speak English. Employee “John” lives at Address = ? . . ?, “Bondstreet” ?
will provide the correct house number, if known. Count: {Employee} = ? . . ? ?
will produce the number of employees known in the information
system.
12. Summary
INFOMOD is a fully specified Conceptual Schema and Information Modelling Language. This paper has described the operations specifications possible in INFOMOD. These
190
D.A. Jnrdtirc, J. 1. vnrt Grietlrrtysett I Specificntiotts itt INFOMOD
specifications have been in practical use for the past two years, and have been found to be easy to learn and use, and to provide unambiguous specifications to implementers. Acknowledgment The authors gratefully acknowledge the kind permission of Philips International BV to publish this paper, the financial support (to DAJ) by the Natural Sciences and Engineering Research Council of Canada, and the comments and suggestions of the editor and the referees. References [l] C.A.R. Hoare. Communicating sequential processes, Cottttn. ACM 21 (1978) 666-677. [2] D.A. Jardine and J.J. van Griethuysen, A logic-based information modelling language, Darn md Knowledge Ettgrg. 2 (1987) 59-81. [3] L. Lamport, Time, clocks, and the ordering of events in a distributed system, Cottm. ACM 2 (1978) 558-565. [4] F.B. Schneider, Synchronization in distributed programs, ACM Trms. Progmttmittg Lnrtgrtnges and Sysretns 4 (1982) 125-148. [S] A. Tarski, Der Wahrheitsbegriff in den formalisieren Sprachen, Studin Philos. 1 (1936) 261-405. Translated as: The concept of truth in formalized languages, in: A Tarski, Logic, Setttnttrics, Metntttnthetttntics (Clarendon Press, Oxford, 1983).