A formal framework for the design of development environments

Abstract

This paper describes a new formalism for specifying development environments for general hierarchical., modular systems. The formal framework is based on a restricted collection of sets and partial functions. formalism are described. Two applications of the In recent years, development environments have been built for many software and hardware systems. The essential similarity of these systems has been concealed by the wide variety of formal techniques that have been used in their description. In this paper, a new formalism is introduced for specifying development environments. The formalism emphasizes hierarchy and modularity, two features that are common to most application areas for which development environm’ents have been constructed. A development environment based on our formalism will include operations that construct and modify systems by selecting components from a library and specifying interfaces between these components. The formalism provides a logically consistent framework for the environment designer which can be adapted to a particular situation by choosing relevant framework attributes. The formal framework is based on a restricted collection of sets and partial functions which are used to define a construction setting, and a collection of basic operations on construction settings. The framework is described using the set-theoretic specification language Z [3]. Two specific applications will be discussed below: a programming development environment for coarse-grain dataflow graphs [ 1,2], and the STILE development environment [4]. In the framework, the lowest level of system components consists of templates, which reside in a common library Lib, which in turn is a finite subset of the basic set Temp. New templates can be added to the library using the EXT operation, described below. Each template has a unique non-empty set of ports, drawn from the basic set Port, which represent. potential interfaces to other templates. The association between templates and ports is defined by the following Z schema: (Note that the symbol --I--> is used in Z to denote apartial function, ,while FlS Perh.SSiOn to Copy Without fee all or part of thii material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice IS given that copying is by perti&on of t.be Assc?=ation for Computing Machinery. To copy otherwise, or DO republish, requires a fee and/or spedic permission. M. D. Rice S. B. Seidman Center for Parallel Computation Department of Computer Science George Mason University Fairfax, Virginia 22030 denotes the set of finite subsets of a set S. The domain and range of a function fare denoted by dom f and ran f.) disjoint {interfaces(t) : t E dom interfaces) The common library Lib is precisely the domain of the function interfaces. The following Z schema defines the owner function from ports to templates: Port-Association 1 TemDlate-Association owier : port --I--> Temp I dom owner = u(interfaces(t) : t E dom interfaces) Vt : dom interfaces 9 interfaces(t) = owner’(t) Notice that the specification of Template-Association is included in that of Port-Association. Each port has an associated set of attributes, which are referenced by the members of an index set AmIndex, which is the disjoint union of the basic sets Struct and NonStruct. Struct will be used to reference attributes referring to relationships between components in a system, while NonStruct will be used to reference attributes referring to such consistency issues as type checking. The set of attributes indexed by iE AttrIndex is denoted Am(i), and the set of all attributes is the disjoint union of the Attr(i). Every template port has a set of attributes, based on an attribute jhction specified by the following schema : Port Attribute 1 Port-Association attr : Port --I--> (AttrIndex ---> Am) dom attr = dom owner The function attr can also be regarded as a partial function Tom the Cartesian product Port x AttrIndex to Am. The templates and ports defined above are used in a construction setting to create larger, more complex objects in a modular fashion. All system components are based on templates selected from the template library. When a template is to be used in a construction setting, it is instantiated by creating a module or node (from the basic set Node) based on the underlying template. The resulting relationship is described by the following Z schema: 01989 ACM O-89791 -305-l /89/0500/0284$00.75 284 Node$kmplate~Association Template-Association node-parent : Node --I--> Temp dom node-parent E FNode ran node-parent = dom interfaces I The domain of node-parent is the collection of all currently instantiated nodes. For each instantiated node, its interfaces or slots are derived from the ports of the underlying template. These interfaces will be used in the construction setting to create relationships with other nodes or with the external environment. Formally, Slot is defined as the subset ((n,p)) of Node x Port whose members simultaneously satisfy the following conditions: n E dom node-parent and p E interfaces (node-parent(n)). The following schema describes the relationships between slots, nodes, and ports: Slot-Association slot-parent : Slot ----> Port owner* : Slot ----> Node slot-parent(n,p) = p owner*(n,p) = n The following commutative diagram summarizes the relationships between slots, nodes, ports, and templates: