لطفا منتظر باشید ...
A.6 Extending PIF
PIF provides a common language through which different process representations can be translated. Because there will always be representational needs local to individual groups, however, there must also be a way to allow local extensions to the description classes while supporting as much sharing as possible among local extensions. The Partially Shared Views (PSV) scheme has been developed for the purpose (Lee and Malone 1990). PSV integrates different ways of translating between groups using different class hierarchies (e.g., pairwise mapping, translation via external common language, translation via internal common language) so as to exploit the benefits of each when most appropriate.A PSV module is a declaration of PIF entities that specialize other entities in the PIF-CORE or other PSV modules on which it builds. The class definitions in a PSV module cannot delete or alter the existing definitions but can only add to them. Examples of PSV modules are given at the end of this section. A group of users may adopt one or more PSV modules as necessary for its task.A group using a PSV module translates a PIF object X into their native format as follows:
If X's class (call it C ) is known to the group and the group has developed a method that translates objects of class C into their native format, then apply that translation method. C is known to the group if either C is defined in one of the PSV modules that the group has adopted or the group has set up beforehand a translation rule between C and a type defined in one of the PSV modules adopted.
Otherwise, translate X as if it were an object of the nearest parent class of C for which rule 1 applies (its parent class in the most specific PSV module that the group and the sender group both share, i.e., have adopted).This translation scheme allows groups to share information to some degree even if they do not support identical class hierarchies. For example, suppose that group A supports only the standard PIF AGENT class, and that group B in addition supports an EMPLOYEE subclass. When group A receives a process description in group B's variation on PIF, they can still translate any EMPLOYEE objects in the description as if they were AGENT objects. What happens to any information that is in an EMPLOYEE object that is not in a generic AGENT object? That will vary according to the sophistication of the translator and the expressive power of the target process representation. However, the translator will preserve the additional information so that it can be viewed by users and reproduced if it is later translated back into PIF.
For example, suppose that EMPLOYEE has a ''Medical-plan''attribute that is not part of the AGENT object in the PIF-CORE. Then group A's translator would:
Translate any Medical-plan attributes into a form that the user could view in the target system (even if it only as a textual comment)[3] AND
When the information is re-translated into PIF in the future (from group A's native format), it is emitted as an EMPLOYEE object with the same value for the Medicalplan attribute (and not simply as an AGENT object with no Medical-plan attribute). MIT researchers are currently investigating this general problem of preserving as much information as possible through ''round trips''from one representation to another and back (Chan 1995).
Translators that can follow these conventions will minimize information loss when processes are translated back and forth between different tools. The details of PSV can be found in (Lee and Malone 1990). In the current version of PIF, each PIF file begins with a declaration of the class hierarchy for the objects described in the file. PSV uses this class hierarchy to translate objects of types that are unknown to a translator. To eliminate the need for PIF translators to do any other inheritance operations, however, all PIF objects should contain all of their attributes and values. For instance, even if the value of a given attribute is inherited without change from a parent, the attribute and value are repeated in the child.As the number of PSV modules grows large, we need a mechanism for registering and coordinating them so as to prevent any potential conflict such as naming conflict. Although the exact mechanism is yet to be worked out, we are envisioning a scenario like the following: The user who needs to use PIF would first consult the indexed library of PSV modules, which documents briefly the contents of each module and the information about the other modules it presupposes. If an existing set of modules does not serve the user's purpose and a new PSV module has to be created, then the information about the new module and its relation to other modules is sent to a PSV registration server, which then assigns to it a globally unique identifier and updates the indexed library. We foresee many other issues to arise such as whether any proposed PSV module should be accepted, and who decides this, and whether to distinguish an ad hoc module designed for temporary quick translation between two local parties from a well-designed module intended for global use. However, rather than addressing these issues in this chapter, we will address them in a separate document as we gain more experience with PSV modules.
To date, two PSV modules have been specified: Temporal-Relation-1 and IDEF-0 modules. The Temporal-Relation-1 module extends the core PIF by adding all possible temporal relations that can hold between two activities (cf. figure A.3). The IDEF-0 module adds the constructs necessary for translating between IDEF-0 descriptions and PIF. IDEF-0 is a functional decomposition model, but it has historically been used widely as a process model description language. IDEF-0 has been used in various ways with no single well-defined semantics. Hence the IDEF-0 PSV module supports translation between PIF and one particular version of IDEF-0. It introduces two additional relations, USES-AS-RESOURCE and USES-AS-CONTROL, as specializations of the USES relation. They are meant to capture the Control and Mechanism input of IDEF-0. The Input and Output relations of IDEF-0 may be translated into PIF by using the Precondition and Postcondition attribute of ACTIVITY. The mapping between IDEF and PIF is shown in figure A.4. These modules have not been offcially registered. They are presented here only to provide examples of PSV modules. We are soliciting further inputs before we register them.
Figure A.3: Possible temporal relations between two activities
Figure A.4: Mapping between IDEF-0 and PIF constructs
[3]If the target representation happens to be PIF (albeit group A's variant of it), the uninterpretable attributes would be stored as text in the User-Attribute attribute, which all PIF entities have.
