Labeled Families in Modular Software Development

Labeled Families in Modular Software Development

Sheila R. M. Veloso and Paulo A. S. Veloso ^*

Programa de Engenharia de Sistemas, COPPE, and Deptº. de Computação, Instituto de Matemática.

Universidade Federal do Rio de Janeiro

21945-970 Rio de Janeiro, RJ BRAZIL

[e-mail]

[e-mail]

José L. Fiadeiro

Deptº. de Informática, Faculdade de Ciências.

Universidade de Lisboa; Lisboa; PORTUGAL.

Campo Grande; 1700 Lisboa; PORTUGAL [e-mail]

Abstract We present a general framework for the modular development of families of programs or specifications through the use of labels. Families, consisting of components or versions, appear naturally in software development. The concept of implementation, as an interpretation into a conservative extension, is generalized to labeled families of specifications and formulated in categorical terms. We also show that the category of such families has pushouts and that this construction preserves conservative extensions, as required for composing implementations.

Key words: Software development, formal specifications, modularity, versions, components, labeled families, implementation, pushouts.

1 Introduction

In this paper, we present a general framework for the modular development of families of programs or specifications, relying on labels to tag their members and their development paths.

Families, consisting of components or versions of software systems (programs or specifications), arise naturally in software development.

The case of components appears often in modular development [2, 4, 7]. A large system is more easily handled if structured into smaller components. In this case, all components must be developed, so that they may be later integrated.

Versions may arise for several reasons. They may reflect the maturity of a software system, as in different releases, say. They may also involve development alternatives that are being (perhaps tentatively) explored, in which case at least one version must be available at the end of the development process.

As an illustration of the latter case, consider the several decisions involved in the development of a (small or large) system. One often does not possess enough information for early evaluation of the merits of each particular alternative. So, one may consider proceeding with the development of some of them until some later stage when preferences become clearer. This strategy, which tends to decrease the likelihood of backtracking, may be favored in the presence of a tight deadline.

Also, these cases may appear in combination, giving rise to versions of components, components of versions, and so forth. In any case, a manager supervising such a process will see a family of software systems. The subsequent development will refine these systems, producing new ones. This process provides development paths for the members of the family.

These considerations lead to the modular development of families of programs or specifications. We will provide here a general framework, based on labeled families, for such ideas.

Labels are being widely used nowadays. Some examples of their use, besides software development, are as traces of deductions of a formula (in labeled deductive systems [6]), as time stamps (in temporal logic and temporal data bases), as numerical evaluation of data to aggregate confidence in some conclusions (in probabilistic and fuzzy systems). Also, the structure of a collection of labeled objects can be mirrored in the label set, recording relationships among members.

The proposed framework generalizes previous work on formalizing modular development of individual programs [5, 9, 12] to families. After motivating the use of labeled families in section 2, we review, in section 3, this previous work on formal software development using logical specifications, using theory presentations and interpretations.

In section 4, we formalize labeled families of specifications and interpretations as a category, and examine some categorical constructions that support the development of such families. In section 5, we concentrate on the modular development of labeled families and develop the notion of implementation. These ideas are further developed in section 6. In section 7, we examine some other issues in the development of labeled families, such as control of members and sharing among them.

2. Motivation: Families and development

We begin by examining some ideas concerning families of software systems (programs or specifications) and their development.

2.1 Families and their development

We first briefly indicate how families of software systems may arise.

Consider a system P consisting of components P' and P". The development of each component may be given to a different team, but a manager supervises the development of a family consisting of systems P' and P".

Now, consider a system P with versions P' and P". Again, the development of each version may be assigned to a distinct team, but a manager will supervise the development of a family consisting of systems P' and P".

As mentioned, the systems involved may have further internal structure.

The development process of both cases may be depicted as in figure 2.1, where members P' and P" are refined to S' and S", respectively.

Figure 2.1: Development process of family

In both cases, the central process amounts to the refinement of families, namely from {P',P"} to {S',S"}, the difference between them residing in the extremes. The case of components begins by decomposing P into P' and P", ending with the integration of S' and S" into S. The case of versions begins by considering versions P' and P" of P, and ends by handling S' and S" into S (say, by selecting one of them or by keeping both).

We thus see that families of systems (programs or specifications) arise naturally in software development. In fact, this view of the development of families is tightly connected to the divide-and-conquer strategy.

2.2 Families and labels

Important issues in the development of families of systems are:

- keeping track of the various members and their relationships,

- selecting the various members and development paths,

- to what extent the members share functional capabilities.

We will examine these and some related issues in the sequel.

Our approach uses labels for handling families and their development.

It is quite natural to regard a collection as tagged by labels identifying its members. The labels, in addition to tagging the members, can also serve for recording some facts, such as strategies, concerning the development.

Consider a system P consisting of systems (components, versions, etc.) P' and P". To record the fact that system P consists of systems P' and P", we may consider a family of systems, labeled by a' and a": P_a':=P' and P_a":=P".

Imagine that these member systems P' and P" are under development, possibly by different teams. Assume that for system P' two refinements are produced, whereas for system P" we have three refinements.

The refinements obtained for system P' may be regarded as forming a family Q of systems, say Q_b' and Q_g ' , similarly, for system P" we have a family R of three systems, say R_b " , R_g" and R_d" , as illustrated in figure 2.2.

Figure 2.2: Development paths for systems P_a ' and P_a"

In supervising the teams, a manager may wish to focus on the overall stage of development. He sees accordingly a single family S with five systems: S_b':=Q_b ' , S_g ' :=Q_g ' , S_b" :=R_b" , S_g" :=R_g " and S_d " :=R_d ". He can keep track of the development of each system by means of the labels, by linking labels b' and g' to a', and b", g" and d" to a", as shown in figure 2.3.

Figure 2.3: Label linking for refinement of systems Pa' and Pa"

Notice that a label link g" a" indicates that system S_g" supports (or, is a refinement of) system P_a". Thus, labels provide useful tools for tagging the various members of a family as well as for keeping track of their development paths along the corresponding fibers. Some label links and development paths for our example are illustrated in figure 2.4.

Figure 2.4: Label links and development paths

These considerations lead to the following idea of refinement of labeled families of systems. A refinement of P=(P_a)_aÎA into S=(S_b)_bÎB amounts to a relabeling r:B®A of their underlying label sets so that S_b is a refinement of Pr(b), as indicated in figure 2.5.

Figure 2.5: Refinement of families of systems PÞS

These ideas motivate examining labeled families of software systems (programs or specifications) and their development.

3 Background: Formal software development

We now briefly review some ideas about modular development of programs from formal specifications [5].

The stepwise approach to formal software development [9, 12] advocates that the specification of the procedures to be implemented be given as a theory presentation in a suitable logic. The starting point of this process of program development is the formal specification of the desired behavior by a set of sentences (a theory presentation). Each development step amounts to the implementation of a specification on another specification, which is intended to be closer to the target programming environment.

3.1 Logical specifications

A logical specifications is a theory presentation, consisting of its language and its axioms, generating its theory. So, we now recall some concepts from formal specifications and logic [3, 11, 12].

We view a (first-order) language L as characterized by its alphabet of extra-logical (predicate, function and constant) symbols together with syntactical declarations. A (logical) specification is a theory presentation, i. e. a pair S=<L,S>, consisting of a language L and a set S of sentences of L (its axioms), generating its theory Cn(S) (which consists of the consequences of its axioms).

Given languages I and K, a translation t:I®K is a syntax-preserving language morphism mapping each symbol of I to a corresponding symbol in K of the same kind; so each formula j of I is translated to a formula t(j) of K. An interpretation from P=<I,G> to R=<K,Q> is a translation t:I®K that translates Cn(P) into Cn(R), which we denote by t:P®R.

We call I a sub-language of K (denoted by IÌK) when K can be obtained from I by adding some extra-logical symbols (and declarations). We say that R=<K,Q> extends P=<I,G> (denoted PÌR) iff IÌK and Cn(P)ÍCn(R). By a conservative extension we mean an extension PÌR such that sÎCn(P) iff sÎCn(R), for every sentence s of I, which we denote by P<R.

3.2 Logical implementations

We now examine implementations of logical specifications.

The purpose of an implementation module is extending the available real machine to a virtual machine. It provides means for creating, on top of the real machine, which has some "concrete" data types, a virtual machine for manipulating "abstract" objects. So, it gives programming formulations for the" abstract" objects in terms of the "concrete" resources.

We can abstract a little from the actual programming details by replacing them by behavioral specifications, which may be regarded as (perhaps incomplete) definitions of the "abstract" objects in terms of the" concrete" ones. With this abstraction in mind, we are ready to describe what is involved in implementing "abstract" A on "concrete" C.

One extends C with new symbols corresponding to those of A (and, perhaps some auxiliary ones) as well as some new axioms giving their properties. This gives rise to a new formal specification B. As one does not wish to disturb the given concrete specification C, this extension B should not impose any new constraints on C. Thus, we require the extension from C to B to be conservative: B adds no new consequence to C in the language of the latter.

One then wishes to correlate the abstract symbols in A to corresponding ones in B. But, the properties of A are important, for instance in guaranteeing the correctness of an abstract program supported by it. Thus, in translating from A to B, one wishes to preserve the properties of A as given by its axioms. This can be formulated by requiring the translation from A to B to be an interpretation of theories: it translates each consequence of A to a consequence of B.

We thus arrive at the concept of an implementation of A on C as an interpretation of A into a conservative extension B (a mediating, or interface, specification) of C [9, 12]. This canonical implementation "triangle" is depicted in figure 3.1.

Figure 3.1: Canonical implementation step

3.3 Logical refinements

We now briefly review some ideas concerning stepwise refinement in the context of logical specifications, i. e. theory presentations.

A useful tool for stepwise development is the structuring of a specification into "context" and "parameter" [3]. The idea is that the context can be plugged into different situations by appropriate choice of values (instantiations) for the parameters. For instance, SEQ[DATA] gives rise to SEQ[NAT], SEQ[CHAR], and so forth.

The simple tools of conservative extension and interpretations between theories provide a quite straightforward account of parameterization and instantiation [9, 12].

In defining the result of a parameter instantiation, one has to complete a diagram with the instantiated specification. The completion of the diagram can be achieved by the pushout construction [8].

We recall that the pushout of interpretations of specifications is constructed as follows (much as in the case of algebraic specifications [3]). Given specifications P=<I,G>, Q=<J,D> and R=<K,Q> together with interpretations r:P®Q and s:P®R, we form the pushout of language translations r:I®J and s:I®K, yielding a language L together with translations 'r:K®L and 's:J®L, which we use to translate the axioms to L and form the specification S=<L,W> with W:='s(D)È'r(Q) . This construction is indicated in figure 3.2.

Languages Specifications

Figure 3.2: Pushout of interpretations of specifications

In composing implementations one faces a similar situation of completing a rectangle to provide a mediating specification for the composite implementation. Now, conservativeness is important for ensuring that the pushout construction indeed provides an implementation. Preservation of conservativeness is guaranteed by the Modularization Theorem [13], as illustrated in figure 3.3.

Figure 3.3: Modularization Theorem

The Modularization Theorem ensures that the pushout construction preserves conservativeness and thus provides a mediating specification for the composite implementation, as depicted in figure 3.4.

Figure 3.4: Composite implementation

In this paper we will generalize the concept of implementation and the modularization theorem to labeled families of specifications.

4 Formalization: Labeled families as a category

The development of families of systems is more complex than that of a single system, because one has to keep track of the development processes of the member systems. For instance, a refinement of families will involve refinements of their members. As indicated, labels provide a good tool for this task, paving the way towards formalization.

We regard collections of software systems (programs or specifications) as labeled families. As indicated earlier, we shall regard refinements as interpretations: language translations that transfer theorems.

4.1 Labeled families of specifications and interpretations

We first formalize labeled families of specifications and interpretations.

A labeled family of specifications amounts to a collection of specifications tagged by labels from a label set. So, a labeled specification family can be described as a pair P consisting of the following data:

- a set A: its underlying label set L(P),

- a family (P_a)_aÎA of specifications P_a=<I_a,G_a >, for aÎA.

We now formalize the idea of refinement of labeled families of specifications as a family of interpretations. As suggested before, we use a relabeling to connect member specifications. We are led to the following concept of labeled interpretation family (see figure 4.1). Given labeled specification families P=<A,(P_a)_aÎA> and Q=<B,(Q_b)_bÎB>, a labeled interpretation family from P to Q is a pair <r,r>where

- r:B®A is a function relabeling their underlying label sets,

- r is a family (r_b)_bÎB of interpretations of member logical specifications, with rb interpreting Pr(_b) into Q_b, for each bÎB.

Relabeling Labels Interpretation

Figure 4.1: Labeled interpretation family <r,r>:P®Q

This formalization of labeled families of specifications naturally suggests a categorical approach, which offers several advantages with respect to conceptual complexity. We can encapsulate a family into a single object of a category, rather than dealing separately with each member. We now show that labeled families of specifications and interpretations form a category and then examine some of its properties and constructions.

We take as objects the labeled specification families and as morphisms the labeled interpretation families.

The appropriate componentwise composition of labeled family morphisms is easily seen to yield such a morphism (see figure 4.2). The composite <r,r>;<s,s>: =<ros,r°_ss> of <r,r>:P®Q and <s,s>:Q®R is a morphism from P to R with (r°_ss)g:=r_s(_g);s_g being an interpretation from P_r[s(g)] to R_g .

Figure 4.2: Composition of labeled family morphisms

This composition of labeled family morphisms is clearly associative.

We also have the obvious identity morphism 1_P on each object P, consisting of identity relabeling 1_L(P) on label set L(P) and identity interpretation on each member specification Pa, for aÎL(P).

We thus have a category, called the category LF of labeled families (of specifications and interpretations).

4.2 Categorical constructions

We now wish to see that the category LF of labeled families (of specifications and interpretations) has pushouts and how to obtain them.

First, in view of the composition in LF, we see that the commutativity of a triangle in LF is equivalent to the commutativity of its underlying triangles: relabeling triangle and interpretation triangles over each fiber, a indicated in figure 4.3.

Commutativity of triangles in category LF

For labeled family morphisms <r,r>:P®Q, <s, s>:Q®R and <t,t>:P®R in LF, <r,r>; <s,s>= <t,t> iff ros=t and, for each label gÎL(R), r_s(g);s_g=t_g.

Figure 4.3: Commutative triangles in LF: relabelings and interpretations

Thus, the pushouts of the category of specifications are reflected to the category LF of its labeled families of specifications and interpretations.

An explicit construction for pushouts in category LF from pullbacks of relabelings and pushouts of interpretations is as follows (see figure 4.4).

Figure 4.4: Pushout in category LF of labeled families

Given labeled family morphisms <r,r>:P®Q and <s,s>:Q®R with common source P in LF, we wish to complete the rectangle.

We first form the pullback of relabelings r:L(Q) ®L(P) and s:L(R)®L(P), yielding a set D as well as functions s':D®L(Q) and r':D®L(R). We take L(S):=D and define labeled family object S=<L(S), (Sd)dÎL(S)> as well as morphisms as follows. Consider an element dÎL(S)=D. Then, by the construction of D, we have labels

b:=s'(d)ÎL(Q) and g:=r'(d)ÎL(R) with common image r(

b)=a=s(g) in L(P). Now, as <r,r>:P®Q and <s,s>:Q®R, we have a pair of specification interpretations r

b:Pa®Q

b and sg:Pa®Rg with common source Pa. Their pushout yields a specification Sd together with interpretations 'sd:Q

b®Sd and 'rd:Rg®Sd. We thus have constructed a labeled family object S=<L(S),(Sd)dÎL(S)> as well as labeled family morphisms <r','r>:R®S, where 'r:=('rd)dÎL(S), and <s','s>:Q®S, where 's:=('sd)dÎL(S), with common target S, in

LF.

It is not difficult to verify that this rectangle is a pushout in LF.

Proposition Construction of pushouts in category LF

Given labeled family morphisms <r,r>:P®Q and <s,s>:P®R with common source P in

LF, consider the labeled family morphisms <s','s>:Q®S and <r','r>:R®S, with common target S, where

- the rectangle r:L(Q)®L(P), s:L(R)®L(P), s':L(S)®L(Q) and r':L(S)®L(R) is a pullback of relabelings, and

- for each label dÎL(S), the rectangle rs'(d):Pr[s'(d)]®Qs'(d), sr'(d):Ps[r'(d)]®Rr'(d), 'sd:Qs'(d)®Sd and 'rd:Rr'(d)®Sd is a pushout of specification interpretations.

Then, the rectangle of labeled family morphisms <

r,r>:P®Q, <s,s>:Q®R, <r','r>:R®S and <s','s>:Q®S is a pushout in the category

LF of labeled families.

In a similar way, we can see that the category

LF has colimits.

5 Development of labeled families

We now examine the stepwise development of labeled families of specifications. First, we will motivate the notion of conservative extension for families of specifications and examine modularity of labeled families of interpretations. We will then proceed to consider implementations of labeled families of specifications and their compositionality.

5.1 Modularity of labeled families

An implementation of families should involve implementation triangles for their members, which we wish to explicate in terms of families of interpretations into conservative extensions, as indicated in figure 5.1.

Figure 5.1
: Implementation triangles for families of specifications

For this purpose, we must generalize the concept of conservative extension to families of specifications.

A refinement of families is a family of refinements of members. Such a family may have some properties that depend on the members. Along these lines, it is reasonable to call an interpretation family a collective (conservative) extension when every member interpretation is so.

Now, a labeled interpretation family from P to Q is a relabeling r:B®A of the underlying label sets together with a family of interpretations between member specifications. We thus call labeled family morphism <c,c>:P®Q a

collective (conservative) extension when each cb:Pc(

b)®Q

b, for

bÎL(Q), is a (conservative) extension, as indicated in

figure 5.2

Figure 5.2: Collective conservative extension

We now examine modularity of labeled families of interpretations of specifications. Modularity, i. e. preservation of conservative extensions under pushouts, is an important asset for the smooth composition of implementation steps. Single presentations over classical first-order logic have the property that pushouts preserve conservative extensions.

By the construction of pushouts in the category LF of labeled families, modularity is inherited by families from their members (see figure 5.3).

Figure 5.3: Collective modularity in category LF

Theorem Collective modularity in category LF

Consider a pushout rectangle of labeled family morphisms <c,c>:P®Q and <s,s>:Q®R, with common source P, yielding <c','c>:R®S and <s','s>: Q®S, with common target S, in

LF. If <c,c>: P®Q is a collective (conservative) extension then so is its pushout <c','c>:R®S a collective (conservative) extension.

5.2 Implementations of labeled families

We now examine implementations of labeled families of specifications and their compositionality. The basic idea of implementation of families involves, as we have indicated, families of implementation triangles. We are thus led to the following notion of labeled implementation family.

A

labeled implementation family of P=<A, (P

_a)

_aÎA> on R=<C,(R

_g)

_gÎC> consists of a mediating labeled specification family Q=<B,(Q

_b)

_bÎB> together with a labeled interpretation family <r,r> from P to Q and collective conservative extension <c,c> from R to Q, as shown in

figure 5.4.

Figure 5.4: Labeled implementation family of P on R

We now turn to the compositionality of labeled implementation families in the category LF of labeled families.

In view of the preceding results, we have an explicit construction for the composition of labeled implementation families, shown in figure 5.5.

Figure 5.5: Composition of labeled implementation families

Theorem Composition of labeled implementation families in LF

Given labeled specification families M, P and T in the category LF of labeled families, consider labeled implementation families:

(1) of M on P, with r:M®Q and c:P®Q into mediating Q,

(2) of

P on T, with s:P®R and k:T®R into mediating R,

and form the pushout in

LF of morphisms c:P®Q and s:P®R yielding a labeled specification family S as well as morphisms 'c:R®S and 's:Q®S. Then, the composites r;'s:M®S and k;'c:T®S (in

LF) give a labeled implementation of M on T with mediating S.

A simple illustration of the composition of labeled implementations is provided by syntactical analysis. In figure 5.5 consider the following families: M, consisting of specifications of parsers (say, top-down, bottom-up, etc.), P, consisting of algorithms for tree traversal (say pre-order, post-order, in-order), and T, consisting of implementations of lists. Examples of software development on industrial scale, even though larger, share the same conceptual pattern.

6 Collective development of labeled families

We now examine some issues in the collective development of families.

6.1 The role of labels

We first examine more closely the role of labels in the development of families of systems.

As mentioned, a system that has distinct labels assigned to it may be viewed as having various versions, which may, or may not, follow distinct development paths, as indicated in section 2 (see figures 2.2 and 2.4).

On the other hand, a labeled family involves only systems with labels: in family P=(P

_a)

_aÎA, one only "sees" the systems Pa for aÎA. This remark is important for stepwise refinement.

A refinement (

P

_a)

_aÎAÞ(Q

_b)

_bÎB of labeled families of systems with underlying relabeling r:B®A will actually provide support only for those systems P

_r(b) with labels r(

b) in the image r[B] of B under r. For instance, a labeled interpretation family <r,r> from P into Q=<B,(Q

_b)

_bÎB> will instantiate only the members P

_r(b) for

bÎB (see

figure 6.1).

Figure 6.1: Labeled instantiation family and relabeling

6.2 Total development of labeled families

We now examine ideas related to developing all members of a family.

Every component of a specification is to be developed into a component of the corresponding system. Also, in the case of alternative versions, one often has not enough information to select one before some development.

In either case, we have an "abstract" family, every member of which is to be developed. Then, each member of the "abstract" family should be supported by a refining system. If we wish every member P_a to be refined we must require the relabeling r:B®A to be surjective. This surjectivity constraint means that each label of the refining family comes from a label of the" abstract" family, for which it provides support.

These considerations lead to the idea of total refinement of labeled families of specifications as follows. A labeled interpretation family <r,r> from P=<A, (P

_a)

_aÎA> to Q=<B,(Q

_b)

_bÎB> is called

total when its relabeling r:B®A of their underlying label sets is surjective. Then, each label aÎA will have a label

bÎB with Q

_b supporting P

_a, as indicated in

figure 6.2.

Figure 6.2: Total labeled interpretation family <r,r>: P®Q

We can see that totality is preserved by pushouts in the category LF of labeled families, as they rely on pullbacks of relabelings.

Totality preservation in category LF

Consider a pushout rectangle of labeled family morphisms <r,r>:P®Q and <s,s>:P®R, with common source P, yielding <s','s>:Q®S and <r','r>: R®S, with common target S, in

LF. If <r,r>: P®Q is total then so is its pushout <r','r>:R®S total.

It is natural to call a labeled implementation family of

P on R total when labeled interpretation family <r,r>:P®Q is total. This suggests the following more constructive formulation illustrated in

figure 6.3.

Figure 6.3: Global labeled implementation family of P on R

Given labeled specification objects P=<A, (P_a)_aÎA> and R=<C,(R_g)_gÎC>, a global labeled implementation family of P on R consists of a (total) labeled implementation family <r,r>:P®Q and <c,c>:R®Q of P on R with mediating Q, and a section *r:L(P)®L(Q) for relabeling r:L(Q) ®L(P), i. e. a function *r such that the composite ro*r is the identity 1_L(P) on label set L(P). The idea is that section *r:L(P)®L(Q) gives a label *r(a)ÎL(Q) with Q_*r(a) supporting Pa, for each label aÎL(P), as shown in figure 6.3.

The pushout construction also gives the composition of global labeled implementation families, as shown in figure 6.4.

Figure 6.4: Composition of global labeled implementation families

Proposition Composition of global labeled implementation families

Given labeled specification families M, P and T in the category LF of labeled families, consider global labeled implementation families:

(1) of M on P, consisting of <r,r>:M®Q and <c,c>:P®Q into mediating Q and section *r:L(M)®L(Q),

(2) of

P on T, consisting of <s,s>:P®R and <k,k>:T®R into mediating R and section *s:L(P)®L(R).

Then, the pushout in

LF provides a labeled specification family S as well as morphisms <c','c>: and <s','s>:Q®S together with a section *s':L(Q) ®L(S), so that the composites <r,r>;<s','s>:M®S and <k,k>;<c','c>:T®S (in

LF) provide a global labeled implementation of M on P (with mediating S) and composite section *s'o*r:L(M)®L(S).

7 Other issues in labeled family development R®S

We now briefly examine some other issues in the development of labeled families, related to control of members and sharing among them.

7.1 Control and extension of refinements in labeled families

We first consider control and extension of refinements in labeled families in connection with the totality requirement.

The totality requirement is not so severe, when we are producing the refining system with its own label set. Also, this surjectivity constraint can always be satisfied by appropriately handling the family, as in the example illustrated by figures 7.1 and 7.2.

Consider a family P with three systems: two components P

_a' and P

_a", later to be integrated, and a third specification P

_a. Assume that we already have produced refinements Q

_b' and Q

_b" for P

_a' but none for P

_a" or P

_a. We are thus in the situation of

figure 7.1.

Figure 7.1: Partial development paths and label assignment

Imagine that we wish to continue the process, producing further refinements for Q_{b '} and Q_{b "}, as well as for P_a", but wish to discard specification P_a. We can record this situation by redressing the preceding refinement step as one of family P to an extended family R where P_a" is refined to itself, as illustrated in figure 7.2.

Figure 7.2: Extended refinement and label assignment

This construction reuses a refinement step PÞQ by incorporating a subfamily refined identically to itself. It can be formalized, and explained, by a product construction. Another application of the product construction is to the parallel elaboration of labeled families. The example of the manager supervising the refinements, in section 2, illustrates this: the manager combines the separated refinements by product.

7.2 Sharing of functionalities in labeled families

Another issue in the development of labeled families is to what extent their members share functional capabilities.

Motivated by the case of extensions of a given theory, we may consider a family of specifications over a common underlying language. In this case, we may also wish to consider refinements that are interpretations sharing a common translation of the underlying languages.

An interesting case comes from default theories. A default theory is a compact way, which leaves some alternatives open, of describing several theories: its extensions [10]. One may regard these extensions as versions of specifications described by the default theory.

This situation can be formulated in categorical terms as follows.

We recall that a (logical) specification P is a pair consisting of an underlying language U(P) and a set A(P) of axioms. An interpretation from <U(P),A(P) > to <U(Q),A(Q) > is a special translation t:U(P) ®U(Q). We thus have a (covariant) functor underlying language U from the category

Spc of specifications to the category

Lng of languages.

Let us call a labeled family specification P=<L(P),(P_a)_aÎL(P) > collectively common when all member specifications are over a common language N(P): U(P_a')=U(P_a"), for all labels a' and a" in label set L(P). Also, for collectively common labeled specification families P=<A,(P_a)_aÎA> and Q=<B,(Q_b)_bÎB>, we call labeled interpretation family <r,r>:P®Q collectively common when all member interpretations have a common translation N(r): U(r_{b '})=U(r_{b "}), for all labels b' and b" in label set L(Q).

Clearly, the collectively common labeled families of specifications and interpretations form a subcategory of the category LF of labeled families, called the category CLF of collectively common labeled families. Also, by construction, the pushout in LF preserves this property (see figure 7.3).

Figure 7.3: Pushout preservation of collective commonality

Corollary Category CLF of collectively common labeled families

The collectively common labeled families of specifications and interpretations form a subcategory CLF of the category LF of labeled families, which is closed under pushouts in LF.

Thus, if we relativize the concept of labeled implementation family to the subcategory CLF of collectively common labeled families (of specifications and interpretations), we still have their compositionality.

8 Conclusion

Families of versions or components of programs (or program specifications) appear naturally in software development, namely in the context of modular decomposition and development strategies that minimize backtracking by exploring, simultaneously, alternative paths. For instance, Lehman and Belady have shown that" large software products tend to evolve into families of versions, each version being similar to, but different from, other members of the family" [1].

In this paper, we have examined some of the issues that arise in the development of such families. Our overall aim is to provide a mathematical framework in which formal support can be given for configuration management databases, version control library systems and other tools that integrate effective configuration management systems.

Our formalization generalizes the concept of implementation developed for single specifications (as interpretation into a conservative extension [9, 12, 13]) to families of specifications tagged by labels. The categorical approach extends the pushout construction to labeled families. This construction was shown to preserve conservative extensions as well as some additional properties such as totality, thereby allowing composition of families of labeled implementation steps.

Summarizing the results presented in sections 4 and 5, we see that the pushout and the colimit constructions play a central role when modeling software development. Pushouts are related to vertical modular development (composition of refinements), while colimits in general are related to horizontal development (integration of components).

Some ideas of our approach are expected to be adaptable to other related situations. For instance, it is apparent that we can extend along these lines the concepts of parameterized specification and parameter instantiation to labeled families.

Finally, it is interesting to point out that the shift from individual specifications to families of specifications, reflecting software development practice, allows us to address two different forms of non-determinism that arise in the development process. When developing programs, the developer faces several design decisions. The developer may take any particular set of decisions as long as the requirements are met. This corresponds to an external choice (under control of the developer), and also to angelic nondeterminism (a successful path is enough). On the other hand, considering a collection of programs where the choice is not under the control of the designer, every one of its members must be developed. This corresponds to an internal choice, and also to demonic nondeterminism. The latter case was treated in the section that discussed total development of labeled families.

References

[1] L. Belady and M. Lehman. The Characteristics of Large Systems. In P. Wegner (ed.) Research Directions in Software Technology. MIT Press, Cambridge, MA, 1979.

[2] R. M. Burstall and J. A. Goguen. Putting Theories Together to Make Specifications. In 5th Internat. Joint Conf. Artificial Intelligence, Cambridge, pages 1045-1058, 1977 .

[3] H. Ehrig and B. Mahr. Fundamentals of Algebraic Specifications, 1: Equations and Initial Semantics. Springer-Verlag, Berlin, 1985.

[4] Feather, M. S. Constructing Specifications by Combining Parallel Elaborations. IEEE Trans. Software Engineering 15(2): 198-208, 1989.

[5] J. Fiadeiro and T. S. E. M. Maibaum. A Mathematical Toolbox for the Software Architect. In J. Kramer and A. Wolf (eds.) 8th Intern. Workshop on Software Specification and Design. IEEE Computer Science Press, Los Angeles, pages 46-55, 1996.

[6] D. M. Gabbay. Labelled Deductive Systems, vol. 1. Oxford University Press, Oxford, 1994.

[7] S. Horowitz, J. Prins and T. Reps. Integrating Non-interfering Versions of Programs. Proc 15th ACM Symposium on Principles of Programming Languages, 1988.

[8] S. Mac Lane. Categories for the Working Mathematician. Springer-Verlag, New York, 1971.

[9] T. S. E. Maibaum, P. A. S. Veloso and M. R. Sadler. A Theory of Abstract Data Types for Program Development: bridging the gap?. In H. Ehrig, C. Floyd, M. Nivat and J. Thatcher (eds.) Formal Methods and Software Development, vol. 2: Colloquium on Software Engineering. Springer-Verlag, Berlin, pages 214-230,1985.

[10] R. A Reiter. A Logic for Default Reasoning. Artificial Intelligence, 13: 81-132, 1980.

[11] J. R. Shoenfield. Mathematical Logic. Addison-Wesley, Reading, 1967.

[12] W. M Turski and T. S. E. Maibaum. The Specification of Computer Programs. Addison-Wesley, Wokingham, 1987.

[13] P. A. S. Veloso and T. S. E. Maibaum. On the Modularization Theorem for Logical Specifications. Information Processing Letters, 53(5): 287-293, 1995.

^*

On leave from Deptº. de Informática, PUC-Rio; 21453-900 Rio de Janeiro, RJ; Brazil.

Publication Dates

• Publication in this collection
  21 Dec 1998
• Date of issue
  July 1998