Kreisel, G.-Krivine, J.L.: Modelltheorie, Springer, Berlin 1972. 15. Lehmann , D.-J.-Smyth, M.B.: Data types. Proc. 18th IEEE Symp. on Foundations of Computing.
V. Claus, H. Ehrig, and G. Rozenberg, editors, Proc. Int. Colloquium on Graph Grammars, LNCS 73, pages 180–191, Berlin, 1978. Springer–Verlag
CONSTRUCTING SPECIFICATIONS OF ABSTRACT DATA TYPES BY REPLACEMENTS H.-D. Ehrich / V.G. Lohberger Abteilung I n f o r m a t i k , U n i v e r s i t ~ t Dortmund Postfach 5oo5oo, 46oo Dortmund 5o, West Germany
Abstract - Categories o f s p e c i f i c a t i o n s , equational s p e c i f i c a t i o n s , and p a r t i a l l y l~partial s p e c i f i c a t i o n s o f a b s t r a c t data types are shown to have pushouts. These r e s u l t s a l l o w us to carry over the machinery o f graph replacement to specif i c a t i o n s . We give some examples. Parametrization is considered as an important special case o f replacement. 1. I n t r o d u c t i o n In the development o f programs and program systems, the i n i t i a l s p e c i f i c a t i o n phase i s o f increasing importance. I t i s essential to have a clean, unique, complete, and implementation independent d e s c r i p t i o n o f what the system is intended to do in order to cope w i t h many problems o f r e l i a b i l i t y . Such a s p e c i f i c a t i o n is not only necessary as a documentation and communication basis f o r the programmer team. Also, l o g i c a l e r r o r s can be detected and debugged in an e a r l y s t a t e , seperate from implementation e r r o r s occuring l a t e r in the implementation process. Moreover, implement a t i o n s or implementation steps can be matched against the requirements of the s p e c i f i c a t i o n , thus c o n t r o l l i n g the correctness o f the program development. The r o l e of s p e c i f i c a t i o n and the r e l a t e d concept of modularity has been studied by Parnas !19] , Liskov and Z i l l e s L19 and others. There is a great need f o r formal methods to support these tasks. Program modules have been modelled by a b s t r a c t data types !16, 13j , i . e . by sets of operations on various domains i n t e r r e l a t e d in a c e r t a i n way. Mathematically speaking, a b s t r a c t data types are a b s t r a c t a l g e b r a i c s t r u c t u r e s . To specify the desired p r o p e r t i e s o f a program module means to specify a class o f a b s t r a c t data types, and t h i s means to give a presentation o f a class o f a l g e b r a i c s t r u c t u r e s . There are well approved methods in algebra and l o g i c to give presentations and i n v e s t i g a t e the s t r u c t u r e o f t h e i r models. Equational presentations and corresponding classes of algebras are e s p e c i a l l y well understood [ i , 2, 4, 5, 6, 9, i i , 12, 18] . S p e c i f i c a t i o n s c o n s i s t o f a set o f s o r t s , a set of operation symbols w i t h i n f o r m a t i o n about t h e i r domains and codomains, a set o f predicates ~ f o r m a t i o n about t h e i r domains, and a c o l l e c t i o n o f conditions or axloms. We give some i n t r o d u c t o r y examples t h a t may serve to i l l u s t r a t e the basic ideas. In our examples, we use a somewhat ad hoc n o t a t i o n which can be viewed to be an informal a l g e b r a i c s p e c i f i c a t i o n language. Example 1.1: The natural numbers w i t h t h e i r o r d e r i n g r e l a t i o n can be s p e c i f i e d as f o l l o w s . Sorts: nat Preds: ~ : nat ~ nat O: ~ nat ~ x ~ succ (x) succ: nat ---) nat x ~ x x~ y^ y~ z~x~ z xm y^ y ~ x~x= y x~yvy~x
181 Example 1.2: The i n t e r v a l I to 10 of natural numbers w i l l be used in the next e'xample. Sorts: ~ : 1 0 ] 0ps: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10: -->[1:10] suc : [ 1 : 1 0 1 4 [1:10] Preds: ~ : [1:10] x [1:1~ Conds: I ~ 2 , 2 ~3 ..... 9 410, x~ y ~ y ~ x ~x =y xcx x~yvy~ x x nat Conds: new 0//(a [ i ] : : n) [ j ] = i f i eq j then n else a ~j] f i I n t u i t i v e l y speaking, a [ i ] := n assigns value n to the i - t h component of array a, while a [ i ] denotes the value stored in that component. Example 1.4.: We extend the previous example by an operation sorting a given array• The f o l l o w i n g operations and conditions are added to those o f the previous example. 0ps: sort: array ~ array ~ d s : i ~ j =)sort(a) [ i ] ~ - s o r t ( a ) [ j ] (3P) [ ( H i ) a [ P ( i ) ~ = sort(a) [i]" A ( P ( i ) = P(j) =7 i = j ) A ( ~ ' i ) (3j) P(j) = i ] The f i r s t condition expresses what i t means f o r an array to be sorted, and the second condition expresses that the contents o f the array may not be changed but only permuted. I f we would l i k e to r e s t r i c t ourselves to equational s p e c i f i c a t i o n s where the conditions are j u s t sets of equations, we could do so by viewing predicates c : x as operations ~ : x - - ~ bool, where bool has two constants, true and f a l s e , equipped with appropriate boolean operations. The f i r s t three examples are e a s i l y r e w r i t t e n in equational form, but there seems to be no way to express the idea of sorting by equations as conveniently as example 1.4 does. One p o s s i v i l i t y is to use an a u x i l i a r y o p e r a t i o n sort1 : array ~ : 1 0 ] - - > a r r a y and express the algorithm of bubble sort by the f o l l o w i n g equations: sort(a) : s o r t 1 ( a : i ) s o r t l ( a , i ) = i f i =%0 then a else _ i f a [ i ] ~ - a [ s u c ( i ) ] then s o ~ t l ( a , s u c ( i ) ) else s o r t 1 ( a ' , l ) f i f i where a' = (aLsuc(i)] := a l l ] ) Llj := a L s u c { i ) ] . We feel t h a t example 1.4 gives a more adequate and easier to understand descript i o n of what sorting means. Although the expressive power o f equational s p e c i f i c a t i o n is p r i n c i p a l l y s u f f i c i e n t f o r a l l practical cases L2, 17] , convenience requires more comfortable s p e c i f i c a t i o n language. In the present paper, we therefore use second-order predicate calculus. With increasing complexitiy of program systems, the design process of s p e c i f i c a tions must be given more and more a t t e n t i o n • A structured and modular approach to s p e c i f i c a t i o n design requires means to manipulate pieces o f s p e c i f i c a t i o n s , put them together, and consistently replace parts of them. For example, i t is very convenient to give s p e c i f i c a t i o n s with formal parts, socalled parametric specif i c a t i o n s , where the formal parts can be replaced by d i f f e r e n t actual s p e c i f i c a tions L6, 7]. Other types of replacement operations occur when s p e c i f i c a t i o n s are to be modified, e.g. to remove errors or to adapt the system to changed user needs
ill.
182
In the f i e l d of graph grammars, methods and tools for handling replacement operations on graphs have been successfully developed and applied to various situations. The purpose of this paper is to demonstrate that these ideas can be carried over to tackle some problems of specification design. In the categorical approach to graph grammars, the mechanisms of graph rewriting have been formalized by means of pushouts in the category graph of graphs ~0, 20, 21]. I t has been realized that these mechanisms can be appITe-d-to any structures forming a category with pushouts C8]. Therefore, we investigate the existence of pushouts in various related categories of specifications. The usefulness of rewritings on these specifications is demonstrated by examples. The techniques and results carry over to p a r t i a l l y labelled partial specifications, which s u i t better to applications. Here, we refer to [21]. In a certain sense, specifications can be viewed as graphs enriched by conditions ConveHsely, i f we forget about the conditions, we get the socalled syntax graph of a specification. Thus, there are forgetful functors from specification categories to corresponding graph categories. I t is shown that these functors respect pushouts. Therefore, specification r e w r i t i n ~ e f f e c t corresponding graph rewritings on the syntax graphs. Parametric specifications can be considered as special cases of rewriting rules, giving the rules how the formal parameter is substituted by the actual parameter. We i l l u s t r a t e by an example how parametric specifications and corresponding specification productions can be used in the editing process of specifications. 2. Categories of specifications and t h e i r graphs Let S be a set of sorts. S~ and S÷ denote the sets of words resp. nonempty words over S. Elements x ~ S~ w i l l be called sorts, too. A signature over S is a mapping ]~ : ~ - - > S . Mappings into a sort set S are called S-sorted sets or simply sorted sets, i f the sort set is clear from the context. Thus, a signature ~ is an S~-sorted set, and i t s elements are called operations. I f ~ ~->xs is in ~ , we call x the domain sort and s the codomain sort o f ~ - > x s
x ~ S~, s c S,
(or j u s t of ~ ). A co-
domain sort always has word length i . 32 determines two mappings: o~ : w ~->x and 7~:~-~s
for e a c h ~ , ~ xs in ~Z, the domain resp. codomain mappings.
We assume that the reader is f a m i l i a r with the category graph of graphs ~0, 20, 21].
A s i g n a t u r e 1 ~ w i l l sometimes be considered to be that graph with nodesS ~,
edges ~
, source f u n c t i o n ~
, and target function%L~. Siqnature morphisms
f :~_i-~2 are those graph morphismus f = (h,g) h : S ~ - - , S ~ , g : ~J 1-~ ~2' where h is a length preserving s t r i n g homomorphism. Thus, h is completely determined by i t s r e s t r i c t i o n to S1 and S2, also denoted by h : S I - - ~ S 2. ÷ If%Z i : ~ i ~ 7 Si , i = 1,2, the morphism condition is equivalent t o / L l h = g]~2 (we write function composition and application from l e f t to r i g h t , e.g. x f and xfg instead of the more conventional f ( x ) and g f ( x ) . ) Let sign be the subcategory of graph consisting of a l l signatures and i t s morphisms. The following r e s u l t carries over form graph.
183 Theorem 2.1: sign has pushouts. Proof: We do not give the complete proof since i t parallels that in the graph case -[I-0-~,20, 21]. For later reference, we give the pushout construction in sign. Let f l : Q l - - ~ Q 2 " f2:Q1--->Q3 be morphisms in sign. We construct Q4' f3:~2--~Q4 ' f4:Q3--~Q4 such that f i g . l ( 1 ) is a pushout: let Q i : ~ i - - ~ S +i and fi=(hi,gi ) for fl £~I--~ (I)
f2
hl > ~2 f
h
f4 ~'~'4
C'~3 . . . . .
gl
SI-
~ S2 (2)
~1
h3
h4 S3--->
g
-~ ~2 (3)
g3
g4 S4
~3
> ~4
figure I i=1, 2, 3, 4, and let h3, h4 and g3' g4 be given such that the diagrams i n f i g . l ( 2 ) and (3) are pushouts in the category set of sets. Due to the definition of morphisms in sign, the diagram in fig.2 is commutative. The upper quadrangle coincides with fig1(3), i.e. i t is a pushout. Thus, there is a unique mapping /// ~4: Q4 ; " " °"~$4 + making the whole diagram in fig.2 commutative.
g,/I2
g3
~2 . . . .
~ ,
g4
/
/ g2
t
iI
h3
figure2
+
----> S4 P~3, /
hI
/
h4
h2
+
•
S1
+
S3
Now we continue to develop our specification language. Given a sort set S, let : ~ - ~ S * be an S~-sorted set of predicates. I f ~ x is in 7-[, x is called the domain of the predicate. We suppose that an S-sorted set_Vi:Vi-~S of individual variables is given, together with an S~-sorted set V~ : V~ --~ S* of predicate variables and an S+-sorted set V~ :V~--->S + of operation variables. Let V=Vi u VuVw .
Let a sort set S, a signature Q, predicates~and variables Vi,V ~ , V~ over S be given, and let all these sets be disjoint. Terms and formulae are now constructed
184
as usual in sorted second-order predicate calculus with equality [ 14]. We shortly introduce our notation. The S~-sorted set T of terms (including term n-tuples) is given as follows:
Definition 2.2: v ~ s eVi
>. ~-~ s ~T
D 2 is a t r i p l e f=(h,g~ ,g~ ) with the properties (i) f'=(h,g~ ) is a signature morphism, f ' : Q 1 --->Q2 (2) g~ : ~ 1 - - ~ 2 satisfies g~ TT2=TTlh (3) for each formula B~ z~I, i f Dlm B, then D2~B~. Composition of specification morphisms is defined by composition of the constituent mappings, separately for each component. I t is easily checked that the c r i t e r i a of a category are satisfied. Definition 2.8: The category of specifications is denoted by spec. By spec= we d'enote the full subcategory of equational specifications. We are now ready to prove our main result: spec and spec= inherit the existence of pushouts from their signatures sign. Let 1~, 1~: be t--~e-forgetful functors T':spec-->sign resp. T'=: spec=--~sign sending each specification to its sig~re-~sidered as a graph). Theorem 2.9: spec and spec= have pushouts. 7~ and T~= respect pushouts. Proof: Let fl:D1--->D2 and f 2 : D I ~ D 3 be specification morphisms in spec. We construct D4, f3:D2-->D4 and f4:D3~D4 as follows (cf. figures I and 2). Let fi=(hi,g~, gi ) ] =(hi'gi )' Di= p r e d : i n t - - > i n t T "pred" u preds I ~t~int 1 "~" i I I
I A
production to substitute nat by i n t
Guided by the d e f i n i t i o n s of total specifications in section 2, by our i n t u i t i o n (example), and d e f i n i t i o n s of p a r t i a l l y labelled partial graphs [21], we give the following precise formulation: Definition 3.1: The category spec-, called the category of p a r t i a l l y (L S, LQ, L~ ) -labelled specifications, has objects D=, where S, ~ , T~, C are items as in the d e f i n i t i o n of spec, except of the requirement that °R, ~o , need only be partial pappings, but those operations and predicates occurring in C must be t o t a l ; and ~ : ( ~ S , ~ , ~ ) is a t r i p l e of three partial mappings ~S: S~--~Ls' ~ : ~ - - ~ L ~ , ~:~---~L~, and this category has morphisms f:D1--->D 2, f=( h, g~ , g ~ ) which obey the same laws as in spec but a d d i t i o n a l l y the l a b e l l i n g of sorts, operations, and predicates is transported by morphisms i f i t is defined. In [ 2 1 ] , the respective morphisms for graphs are called "weak morphisms". Theorem 3.2: spec- has pushouts. proof: The argument is as with spec, although we must be careful with some of the arrows because of the p a r t i a l i t y - - ~ the involved mappings. /// In analogy to the discussion of the last section, the same result holds for the subcategories of spec- determined by a special calculus, as e.g. equational calculus or f i r s t ~ e r predicate calculus. A pushout diagram in such a specification category implies a pushout diagram in the underlying graph-category, i . e . we have a forgetful functor from the specification catagory to the graph category respecting pushouts.
188 We h i n t f u r t h e r that i t is useful f o r practical s i t u a t i o n s to be sure that applying a production to a t o t a l s p e c i f i c a t i o n y i e l d s a t o t a l s p e c i f i c a t i o n , even i f t h i s production consists o f p a r t i a l s p e c i f i c a t i o n s . [ 2 1 ] give s u f f i c i e n t c r i t e r i a f o r t h i s problem in the graph case, which carry over to the spec case. We give an example in f i g u r e 4 to demonstrate that i t is conveniently possible to use productions f o r r e l a b e l l i n g of operations. Here, the p a r t i a l i t y of operations provides the economy of specifying not more than required. This production can be applied to any s p e c i f i c a t i o n where we f i n d an analysis pushout. Obviously, a l l other labels of the analysed s p e c i f i c a t i o n are saved via the pushout-complement. 'B ops su---Ec: ~
K •
Figure 4:
: l "succ">
,
, ops P i~ .-->
B' .
' I ~
, !ops p ~: ~-T-.".
: --->
.
1
"N"
'
production to relabel the successor operation
4. Parametric s p e c i f i c a t i o n s Parametric s p e c i f i c a t i o n s are a very convenient means f o r the s p e c i f i c a t i o n process. We do not care about semantical problems of parametric s p e c i f i c a t i o n s c f . [ 1 5 ] , but discuss a more s y n t a c t i c a l l y oriented treatment f o l l o w i n g [ 7 ] . To give an example, the concept of an array is rather independent of the type of i t s entries and keys. The only requirement is that there should be an " e q " - r e l a t i o n on keys and a constant entry serving as the value of new(i). Thus we would l i k e to give s p e c i f i c a t i o n s as follows. Example 4.1: The parametric s p e c i f i c a t i o n of array(key, entry) is: params key, entry, eq, 0 sorts
array, key, entry
ops
0 :-->entry new:~array .[.I:=. : array~key~entry--~array .[.] : array~key--~entry if.then.else.fi : bool×entry-entry--~entry
preds
eq : key×key
conds
new[i I = 0 (a[il:=n)[jl
= i f i eq j then n else a [ j ] f i
We denote the formal parameter part by the params symbol. In spec-, an embedding w i l l serve f o r t h i s purpose. A parameter ass-ignment should m a ~ r m a l parameters to actual parameters which s u i t in type and behaviour. So, assignments are well modelled by morphisms. To apply a parametric s p e c i f i c a t i o n to an actual parameter is intended to s u b s t i t u t e the formal parameter s p e c i f i c a t i o n by the actual parameter s p e c i f i c a t i o n and t h i s is done by the pushout construction. D e f i n i t i o n 4.2: A parametric s p e c i f i c a t i o n p:F--~P is an embedding in spec-. ~ ~ - ~ s i g n ~ : ~ ~ r p h i s m f : F - ~ A . The r e s u l t of-'-tF~e a p p l i c a t i o n of the parametric s p e c i f i c a t i o n p:F--~P to the actual parameter A via f:F--~A is the pushout-object o f the pushout of p and f . In our examples with arrays, 1.3 and 4.1, we have:
189
(key, entry)
) array (key, entry) p.o.
I
( [ I : 1 0 ] , nat)
>array ( [ 1 : 1 0 ] , nat)
Not that the actual parameter A can i t s e l f be a parametric s p e c i f i c a t i o n q : E--->A with a formal parameter part E. Thus, sequences of applications of parametric s p e c i f i c a t i o n s can be constructed. The f o l l o w i n g r e s u l t f o r spec = ~ , ~ carries over to ~P~F and spec -: Theorem 4.3: The a p p l i c a t i o n of parametric s p e c i f i c a t i o n s to parametric speci~ i c a t i o n s i s associative. When we have a parametric s p e c i f i c a t i o n , we can use i t as well as a production by d u p l i c a t i n g the parameter. The idea is demonstrated by figures 5 und 6. params
d,~
sorts
d
preds
~ : d ~ d
conds
x ~ x x ~y ^ y~
z==~x ~ z
x ~y ~ y£ x ~ x = y x~y ~y~x Figure 5: Parametric specification of a total ordering [.
'
.
.
.
.
.
.
preds
~: _
-~
d~d
L . . . . . . . .
~ ~(
~
V ,
preds
~ : d~d
I
--
L . . . . . . . .
I
F
~
.
.
.
.
.
.
,J preds 'P
[
.
-
.
~:d~d I I
conds
II I q
I
I X ~
X
I I I
x~ y~y~ z~x ~ z x~_ y A y ~ x ~ x = y
I
x-~yvy~x
I
,
1 I
}
b . . . . . .
Figure 6: Production to generate t o t a l orderings Taking parametric concepts, supplementing them to productions, and storing these productions in a l i b r a r y is a promising tool f o r e d i t i n g s p e c i f i c a t i o n s . Using the production o f f i g u r e 6, when we want to specify any s i t u a t i o n where a t o t a l ordering is involved, we need only give the few axioms that determine the s p e c i f i c ordering. For example, f o r natural numbers we need only give sorts: ops: preds:
nat 0 : - - ~ nat succ: n a t - - - ~ n a t ~ : nat × nat x
~ succ(x)
190 Applying the production of figure 6 to this specification, the ordering axioms are inserted, and we get the specification of example 1.1. We can imagine that for more complex concepts there may be a considerable economy in using parametric specifications as replacement rules or productions. 5. References I. ADJ (Goguen, J.A.-Thatcher, J.W.-Wagner, E.G.): An i n i t i a l algebra approach to the specification, correct ness, and implementation of abstract data types. Current Trends in Programming Methodology IV, ed. by R. Yeh, Prentice Hall, New Jersey 1977 2. ADJ (Thatcher, J.W.-Wagner, E.G.-Wright, J.B.): Data type specification, parametrization, and the power of specification technigues. Proc-Sigact Annual Symp. Theory Comp., 1978 3. Brendel, W.-Bunke, H.-Nagl, M.:
Syntaxgesteurte Programmierung und inkrementelle Compilation. Proc. GI-7. Jahrestagung, Informatik Fachberichte i0, 57-73, Springer Berlin 1977 4. B u r s t a l l , R.M.-Goguen, J.A.: Putting theories together to make specifications. Proc. 5th IJCAI 77, MIT, Cambridge, Mass. 1977 5. Ehrich, H.-D.: Extensions and implementations of abstract data type specifications. Proc. MFCS'78, ed. by J. Winkowski, Lecture Notes in Computer Science, Vol. 64, Springer-Verlag, Berlin 1978, 155-164 6. Ehrich, H.-D.: On the theory of s p e c i f i c a t i o n , implementation , and parametrization of abstract data types. To be published 7. Ehrich, H.-D.-Lohberger, V.G.: Parametric specification of abstract data types, parameter s u b s t i t u t i o n , and graph replacements. Proc. Workshop "Graphentheoretische Konzepte in der Informatik", Applied Comp. SC., Carl Hanser Verl., Muenchen-Wien 1978 8. Ehrig, H.-Kreowski, H.-J.-Maggiolo-Schettini, A.-Rosen, B.K.- Winkowski, J.: Deriving structures from structures. Proc. MFCS 1978, ed. by J. Winkowski, Lecture Notes in Computer Science, Vol. 64. Springer-Verlag, Berlin 1978, 177-19o 9. Ehrig, H.-Kreowski, H.-J.-Padawitz, P.: Stepwise specification and implementation of abstract data types. Proc. 5th Intern Colloq. on Automata, Languages, and Programming, Venice 1978 Io. Ehrig, H.-Pfender, M.-Schneider, H.-J.: Graph-Grammars-an algebraic approach. Proc. Conf. Switch. Automata Theory 1973, 167-18o 11. Goguen, J.A.: Correctness and eqivalence of data types. In: Proc. Conf. on Alg. Syst. Th., Udine, Lecture Notes In Comp. SC., Springer-Verl., Berlin 1975 12. Goguen, J.A.: Abstract errors for abstract data types. In: Proc. Conf. on Formal Description of Programming Languages, Ed. by E.J. Neuhold, North-Holland Publ. Company, Amsterdam 1976
191 13. Guttag, J.V.: The specification and application to programming of abstract data types. Techn. Report CSRG-59, Univ. of Toronto 1975 14. Kreisel, G.-Krivine, J.L.: Modelltheorie, Springer, Berlin 1972 15. Lehmann , D.-J.-Smyth, M.B.: Data types. Proc. 18th IEEE Symp. on Foundations of Computing. Providence R.I., 1977, 7-12 16. Liskov, B.-H.-Zilles, S.N.: Specification Tehcniques for data abstractions. IEEE Transact. Softw.Eng., Vol. SE-I (1975), 7-19 17. Majster, M-E.: Data types, abstract data types and their specification problem. Report TUM-INFO-774o, Techn. Univ. Muenchen, 1977 18. Manes, E.G.:
Algebraic Theories. Springer-Verl., New York 1976 19. Parnas, D.L.: A technique for module specification with examples. Comm. ACM 15 (1972) 33o-336 2o. Rosen, B.K.: Deriving Graphs from Graphs by applying a production. Acta Informatica 4, 337-357 (1975) 21. Schneider, H.J.-Ehrig, H.: Grammars on partial graphs. Acta Inf. 6, 297-316 (1976)
