Common interface-based specification techniques are limited in their ability to deal with dynamics, architecture, and quality of service. An interface alone defines only ``syntactic'' conformance: Implementations must respond to the listed operations. An interface adorned with descriptions of the nature of operation arguments and results defines per-operation functional conformance. But even this does not always provide sufficient information for designers and implementors to ensure that components in open systems behave as desired. For example, a new interface-compatible component may not actually interoperate with an existing one if it fails to send the same kinds of messages to other components in the course of providing services.
These kinds of dynamic and architectural issues often overwhelm those surrounding service functionality. Descriptions of connection and communication patterns among components are more central in the characterization of many systems than are descriptions of services [22,21,28].
PSL is a framework for addressing such issues by extending the interface-based description of open systems to capture the questions of who, what and when across interactions, as well as the structural relations underlying these dynamics. The principal abstractions include:
PSL specifications describe dynamic and architectural matters without pinning down implementations, connections or communication mechanisms. PSL remains faithful to the distinctions between interfaces versus implementations that permit the development of open systems, while still providing a means to specify that implementations obey necessary interoperability constraints. PSL does not assume any specific computational model or mechanics relating roles and implementation objects. Descriptions of how each instance of a role is mapped to one or more implementation objects (and vice versa) lie outside of PSL.
PSL captures the essential incompleteness of open systems by specifying sets of properties and constraints without claiming that these fully describe a system, or ruling out the existence of unmentioned components, situations, or events. Thus, PSL lacks some familiar constructs found in ``closed-world'' formalisms. In particular: (1) PSL does not support the use of frame axioms asserting that properties that are not otherwise mentioned in one situation are not changed from those in predecessors. (2) PSL does not contain step operators asserting that given states occur at the ``next time step'' after others; thus that there are no intervening situations. ( Step is also implicit in the description of transitions in most state models.) (3) PSL does not support leaf interfaces asserting that interfaces have no possible extensions; thus that instances do not support additional operations. (4) PSL does not contain any notion of a leaf state asserting that a situation has no possible further decomposition; thus that no unmentioned events may exist.
Thus, anything that is not ruled out is assumed to be possible. However, stronger specifications may be introduced via refinement. Protocol refinement is the act of introducing new rules within a narrower context than more general rules, but without invalidating these more general rules. The opposite of refinement is generalization, in which a weaker set of rules is introduced in a broader context.
Additive refinement may take either of two forms. Versioning based refinement is the act of inserting or extending rules within an existing context, adding greater specificity or enhancements in successive versions during the course of initial development and/or system evolution. Specification frameworks themselves cannot provide direct support for versioning, although compatible tools would facilitate use. Specializations are additions that are localized to new entities, described by new interfaces bearing subinterface relations to the originals. PSL supports specialization by extending common subtype-based tactics. New subinterfaces may extend interfaces, new subsituations may extend situations, and new ordering constraints on new situations may extend those described in existing rule sets.
PSL is designed to support methods and tools for developing components in open systems; formal specification analysis is only a secondary goal. It is in principle possible to build or adapt inference tools (e.g., [43]) that check collections of PSL rules for consistency, and to answer questions about their properties. For example, one could ask which exceptions might be expected in a system from a given starting point. However the nature of open systems and their specifications preclude certain categories of analytic questions and answers. Specification systems (see Section 6) based on ``closed world'' assumptions (i.e., that the system implements only those features specified) are uniformly more powerful than PSL in addressing questions about liveness, deadlock, interference, and aliasing [49,31]. Such questions often have no definitive answers in open systems. While a selected set of PSL rules can be analyzed in ``closed system mode'', under the assumption of complete knowledge, there is no use in doing so unless one has independent assurance that the relevant portion of the system is fixed and communication closed with respect to the rest of the system for all time (i.e., produces no outputs except replies to procedural requests). While closed-world models may have a place in open system development, they are perhaps best applied to descriptions of classes and objects. Object implementation code does what it does, and nothing more. While interface-level open system development cannot exploit this fact, it is sometimes profitable (but see [37]) to rely on fixed known implementation properties when constructing individual components.