next up previous
Next: Appendix Up: PSL: Protocols and Pragmatics Previous: Methods and Tools

Related Work


Protocol specification, architectural description, and approaches to dynamics in general have a long history. While all such approaches may be related at some level, they differ significantly in their theoretical bases, definitional primitives, and range of usability. The ways in which PSL constructs support interface-based specification of open systems distinguish it from other frameworks:

Preconditions and Postconditions [30] and specification systems based upon them [36], employ the construct { A } s { B }, asserting that program fragment s brings a program from a state obeying A to one obeying B. The PSL constructs A B and A B have similar usages, but split the different senses of this relation when applied to ordered events. PSL may be used to express the kinds of assertions typically associated with operation postconditions, but applies them to arbitrary ``evaluation points'' rather than necessarily only upon issuance of a reply. PSL does not include any language-specific operational semantics, and omits reference to s. PSL also differs in its scoping and parameterization of predicates.

Abstract Data Types (ADTs) [40,62] describe functional properties of ``black box'' components via preconditions, postconditions, and invariants, without describing the nature of their dynamic dependencies or interactions. PSL attributes and constraints share a similar basis, but are used primarily to describe interaction constraints.

Architecture Description Languages (ADLs), module interconnection languages, and related approaches [41,4] usually extend an ADT-style basis to describe static configuration and communication properties of sets of components. This focus on statics varies in degree across languages. PSL may be construed as variant ADL best suited for systems with few fixed configuration properties beyond those of their general purpose communication substrates; for example, ORB-mediated communication in CORBA systems.

Object-Oriented Analysis notations [61,34,19] describe classes of objects in terms of attributes, relations, states, operations, and messaging, at varying degrees of formality. PSL generalizes, extends and reworks the dynamic aspects of such concepts to apply to interfaces of components in open systems, in a manner compatible with other role-based frameworks [6,60,68,26]. Unlike some other approaches [2,71] that add protocol specifications to object-oriented interfaces, PSL does not assume any particular model or mechanism relating these interfaces and roles to classes and objects.

Linguistic Approaches to Pragmatics [51] address the context-specific dynamics of communication (speech acts) among participants, while semantics abstracts over situations to address context-independent meanings. This distinction provides a useful conceptual basis for approaching these qualitatively different aspects of interaction, and serves as a guide to the kinds of phenomena that PSL is intended to capture.

Process Calculi [47] and specification languages based upon them model systems as collections of abstract processes communicating via messages, where each process and communication act obeys a particular abstract computation model. In contrast, PSL specifications are non-constructive. They do not rely on a particular computational model beyond that implied by minimal assumptions about message passing in open systems. PSL specifications contain sets of constraints on behavior that may be implemented by any kind of component meeting the constraints.

History-based Frameworks [45,50,33,14,23] specify actions that occur under given patterns of event histories. These patterns are most often described in terms of regular expressions or variants thereof. Because PSL deals with roles in potentially distributed systems, events as seen by a given instance are not necessarily totally orderable. They can be ordered only by , not the strict relation that may be seen by any particular implementation object. Thus PSL history patterns cannot be described as languages or regular expressions [57]. They are instead indicated by linked situations. Also, an event occurrence is construed in PSL as just one kind of attribute (although one with a special interpretation) ascribable to a role. Other kinds of attributes can be defined as well. For example, one set of instances of a File interface may be ``born'' in an isOpen state, while others are not.

Event-based Frameworks [38,57,10] are typically based on orderings defined over raw events. The PSL relation serving as the basis for protocol operators is defined in a fashion similar to such orderings, but ranges over abstract instances of situations described via event predicates and other arbitrary attributes, not instances of events themselves. When restricted to event predicates, these are related in a simple way under the intended mapping to raw events: If the instances of two events are ordered, then so are the corresponding instances of event predicates. PSL operators, situations, and partitionings are more closely related to corresponding constructs in event structures and its variants [70,24,58], as adapted for use in interface-based specification.

next up previous
Next: Appendix Up: PSL: Protocols and Pragmatics Previous: Methods and Tools

Doug Lea@Sat Jun 3 07:20:05 EDT 1995