This report describes PSL, a framework for specifying dynamic and architectural properties of open systems. The remainder of this section provides background on the interface-based specification of open systems. Section 2 discusses the nature of protocol specification in open systems. Section 3 describes PSL concepts and notation, illustrated in more detail in Section 4. Section 5 surveys prospects for associated methods and tools. A discussion of related work appears in Section 6. The Appendix contains a few technical details omitted from the main presentation.
Open systems have been defined [29,1,67] as encapsulated, reactive, and spatially and temporally extensible systems: They are composed of possibly many encapsulated components, each of which is normally described as an object. Each component supports one or more public interfaces. The inner workings of each component are separately specified via a normally inaccessible implementation description (often a class). Open systems are reactive in that they do not just perform a single one-time service; most functionality is provided ``on-demand'', in reaction to a potentially endless series of requests. Open systems are spatially extensible when components need not bear fixed connectivity relations among each other. They may interact via message passing mechanisms ranging from local procedure calls to multi-threaded invocations to asynchronous remote communication. And open systems are temporally extensible to the extent to which their components and functionality may be altered across a system's lifetime, typically by adding new components and new component types (perhaps even while the system is running) and/or updating components to support additional functionality.
For example, an open system supporting financial trading might include a set of components that ``publish'' streams of stock quotes, those that gather quotes to update models of individual companies, those serving as traders issuing buys and sells of financial instruments, and so on. Such a system relies on interfaces (e.g., QuotePublisher) with multiple implementations. It contains reactive components handling a constant influx of messages. It is intrinsically distributed in order to deal with world-wide markets. And it may evolve in several ways across time; for example to accommodate a new company listed on an exchange, or to replace components computing taxes with interoperable versions reflecting tax law changes.
Interface declarations provide a basis for specifying capabilities in open systems at varying levels of precision and formality. An interface describes only those services that other components may depend on, in terms of a set of constraints (e.g., a collection of required operation signatures [9]) on a family of components, not necessarily a complete or closed (nonextensible) description of any given component. Any implementation(s) that provide required functionality may be used.
Subtyping regimes over interfaces allow one interface to be described as an extension, refinement, or specialization of one or more superinterfaces. Conversely one interface may abstract a subset of the functionality described in one or more subinterfaces. Typically, base interfaces describe only those operations that are involved in a set of related interactions, and ``fatter'' interfaces are derived via multiple inheritance [53]. One interface type may describe only certain aspects features that are listed more completely in various subinterfaces. At an extreme, an interface might include only a single service operation. Interface subtyping allows systems to include multiple interoperable implementations of common services, and sets of component types that specialize on common core features.
Systems constructed according to the OMG [52] CORBA model are among the best examples of the interface-based approach to development. In CORBA, component interfaces are described in CORBA IDL, an interface description language indicating only the functional properties of provided services in terms of operation signatures. Implementations are often process-level components distributed across machines, communicating via message passing mechanisms mediated by an object request broker (ORB) that directs requests to their destinations.
While not always phrased as such, interface-based specification intrinsically relies upon the distinction between roles [68,60,6] and the components that implement those roles. This distinction is similar to that between a role in a particular play performance (e.g., Hamlet) and the actor or actors playing the role (e.g., Richard Burton or Lawrence Olivier). A role may also be thought of as a typed, abstract access channel [65,4] providing a view [63] of one or more interaction participants [34], where each view is described by an interface that lists a set of supported message types. This concept of a role is nearly synonymous with that of a subject in the essential sense of Harrison & Ossher [26]. In ordinary usage, the term ``role'' is sometimes applied to a description of a role rather than its instantiation. We reserve the term ``interface'' for descriptions, and just ``role'', or for emphasis, ``role instance'' for instantiations.
Interface specifications describe roles without commitment to the computational entity or entities that may implement them. Thus, the notion of a role is distinct from the programming-level notion of an implementation object. In fact, components need not be conceptualized as objects in the usual narrow sense of the term. Implementation objects may also consist of finer-grained instantiations (activations) of single procedures, or coarser-grained process-level components.
While roles are not the same as implementation objects, they bear several definitional similarities in terms of identity, state, and behavior [11,19]:
In classic modular development methods, there is typically exactly one implementation type per interface type and vice versa. In most object-oriented languages, there may be multiple implementation subclasses per interface. But in general, interface-based specification admits a many-to-many relationship between roles and objects:
For example, an OfficeManager role might be implemented using a Person object, or a Robot object, or a set of job-sharing Persons, or even a mechanism causing a new SpecialtyWorker object to be constructed to handle each incoming service request. A Person object might additionally play the roles (hence ``export'' the interfaces) of Parent, Driver, Customer, etc. perhaps all at the same time. Multiple interface instances, each seen from a different client, may access the same Person implementation:
Any of a number of programming constructs and infrastructure schemes can be used to support these kinds of mappings. For example, most CORBA systems reify some aspects of roles as ``interface objects'' that support some of the possible mappings by relaying messages to implementation objects. Other infrastructures (e.g., [10]) connect role-based messages via channels to multiple objects that together implement the role. In non-distributed frameworks, interfaces and implementations are (often incompletely) separated through programming language mechanisms and conventions. For example, Modula-3 and Ada9X contain interface types useful for open system development, and C++ and SmallTalk programs often use ``abstract classes'' and related constructs to distinguish interfaces from implementations. Finally, it is very possible to apply these concepts in systems in which roles are never explicit at the implementation level, and so are used only as abstract design constructs ( [60]).