لطفا منتظر باشید ...
A.3 PIF Overview
The PIF ontology has grown out of the efforts of the PIF Working Group to share process descriptions among the group members'various tools. We have used the following guidelines in developing this hierarchy:
Generality is preferred over computational effciency when there is a trade-off, for the reason that PIF is an interchange language, not a programming language designed for effcient execution.[2] Therefore the organization of the entity classes is not necessarily well suited to performing any particular task such as work flow–management or process simulation. Instead, our goal has been to define classes that can express a wide variety of processes, and that can be readily translated into other formats that may be more suitable for a particular application.
The PIF constructs should be able to express the constructs of some existing common process representations such as IDEF (SADT) or Petri nets.
PIF should start with the minimal set of classes and then expand only as it needs to. The minimal set was decided at the first PIF Workshop (October 1993) by examining those constructs common to some major existing process representations and to the process representations used by members of the PIF Working Group.
section A.6), so new classes or attributes should be added to the standard PIF classes only if they seem to be of suffciently general usefulness.
A PIF process description consists of a set of frame definitions, which are typically contained in a file. Each frame definition refers to an entity instance and is typed (e.g., ACTIVITY, OBJECT, TIMEPOINT) and they form a class hierarchy (see figure A.1). A frame definition has a particular set of attributes defined for it. Each of the attributes describes some aspect of the entity. For example, a PERFORMS definition has an Actor and an Activity attributes that specifies who is performing which activity. The instance of a frame definition has all the attributes of all of its superclasses, in addition to its own attributes. For example, all the instances of ACTIVITY have the Name attribute, since ENTITY, which is a superclass of ACTIVITY, has the Name attribute.
Figure A.1: PIF class hierarchy
When an attribute of one frame has a value that refers to another frame, the attribute represents a relationship between the two instances that the two frames refer to. For example, if the Begin attribute of ACTIVITY-1 takes TIMEPOINT-32 as its value, then the Begin attribute represents a relationship between the ACTIVITY-1 and TIMEPOINT-32 instances. The value of a given attribute in a PIF file holds independent of time. Figure A.2 depicts the relationships among the PIF classes. Section A.5 describes all of the current PIF classes.
Figure A.2: Relationships among PIF classes
An attribute in a PIF entity can be filled with the following and only the following PIF expressions: a literal value of a PIF primitive value type or an expression of a composite value type. The PIF primitive value types consist of NUMBER, STRING, and SYMBOL:
NUMBER. A numeric value. The NUMBER type is subdivided into INTEGER and FLOAT types.
STRING. A sequence of characters.
SYMBOL. Symbols are denoted by character sequences, but have somewhat different properties than strings. PIF symbols are a much-simplified version of symbols in the Lisp programming language (Steele 1990). In PIF, the main difference between strings and symbols is that symbols are not case-sensitive unless specially quoted, but strings are always case-sensitive.
The PIF composite value types consist of LIST and PIF-SENTENCE:
LIST. A list.
PIF-SENTENCE. A logical expression that evaluates to TRUE or FALSE.
An object variable is of the form, object-name[.slot-name]*, which refers to either the object named or the object which is the value of the named slot (or, if there are more than one slot-names specified, the object which is the value of the named slot of the object which is the value of the next named slot, etc.)[2]Although PIF is not an execution language, an execution language can be PIF-compliant. That is, an execution language can be designed to include the PIF constructs and thus not to require a translator to process a set of PIF speci?cations.
