Type Systems, Software Architecture and Testing
Stuart O. Anderson Daniele Compare
LFCS, Department of Dip. Di Mat. Pura ed Applicata
Computer Science Universita' dell'Aquila
University of Edinburgh Via Vetoio, Localita' Coppito
Edinburgh EH9 3JZ, UK L'Aquila, Italy
+44 131 650 5191
ABSTRACT I give two short examples of di erent styles of type sys-
Modern type systems for programming languages o er tem used in SML to give some idea of the range of
an expressive language for talking about software com- information derivable. Because space is short the ex-
ponents and provide tools that o er thorough analysis amples are small but I believe they could be scaled up
of such components and their interconnection. We ar- quite easily. In both examples I choose to use pipe and
gue that many of the concerns in testing and analysis of lter style architecture, other styles can be accommod-
software architectures are also the concerns in the pro- ated.
gramming language type system community but they SML consists of two almost completely independently
are expressed in somewhat di erent terms. We exem- de ned parts. The core is a call by value functional
plify this using small examples drawn from Standard language with some imperative features. The typing
ML and Extended ML. We also point out some recent mechanism in the core is type inference which means
developments in type systems that may be of relevance that the user of the system can omit typing information
to the software architecture community. completely and the system will infer the most general
KEYWORDS type for any expression. The module system of SML is
type systems, Standard ML, polymorphism, module intended as a notation for describing how to build ML
systems, interface speci cations, test case generation, systems. It is explicity typed. The user of the system
adequacy of test cases must include type annotations and the system checks
Over the past two decades the programming language they are satis ed by the program.
design community has developed increasingly sophist- 1 Core SML: Polymorphic Type Inference
icated type systems. These o er well-packaged and
powerful tools for the analysis of programming systems. In the core of SML types are built up from constant
These systems are usually decidable and include fea- types: e.g. bool, int and unit the one element type
tures such as polymorphism of various kinds, higher whose value only value is , the empty tuple; type
order objects, and more recently subtyping and inherit- variables: written 'a, texttt'b and type constructors
ance. Type systems generally fall into two kinds: those that generate new types from old: e.g. a*b is the type
that check type annotations are correct and those that of pairs, and a - b is the type of functions from a to
b. The set of type constructors is not xed, there is a
infer the type of objects in the system. Cardelli 1
provides an excellent survey of much of the work in the basic set that can be extended as necessary.
area. In this section we will use the example shown in Fig-
The position I hold is that modern type systems can be ure 1. This is a simple pipe and lter architecture
of great value in analysing and testing software architec- where the lters are represented by circles, pipes by the
tures. Here, my argument for this position is to provide arcs and the component in the square is not a lter but
a couple of simple examples of architecture descriptions rather something that generates some kind of summary
in a language with a modern type system Standard ML of its input on its output.
SML 3 . My position is not that SML is the ideal Ar- Implementing such an architecture in SML is fairly
chitecture Description Language ADL. My argument straightforward . The stream type constructor is intro-
is that work on ADLs could be enriched by work on duced to model in nitely proceeding streams and then
Type Systems and that some information derived from the skeleton components are de ned.
type systems can help in the testing of architectures.
The Type System literature has not been completely datatype 'a stream =
ignored, see 2 , but I feel it could be given greater at- 1 This is not intended to be an e cient implementation. It
tention. contains a number of signi cant ine ciencies.
* p1 HH
fm - gob
is the generic form of the architecture that can be spe-
cialised by supplying speci c functions that implement
the component operations at the nodes in the diagram.
The type inference system of SML responds with the
following typing for the system. The types allocated are
S H p2
the most general possible in the sense that any other
typing of the term is obtainable by substituting some
type for a type variable in the type. Here is the system
datatype 'a stream =
Figure 1: A Simple Architecture NEXT of unit - 'a * 'a stream
val NEXT : unit - 'a * 'a stream -
NEXT of unit - 'a * 'a stream
val filter : 'a - 'b -
'a stream -
fun filter f NEXT t = 'b stream = fn
NEXTfn = let val v,s = t val gobble : 'a - 'b * 'b stream -
in 'a - 'b stream = fn
f v, filter f s val merge : 'a - 'b - 'c - 'a stream -
end 'b stream - 'c stream = fn
val sys : 'a - 'b -
fun merge f NEXT t NEXT t' = 'b - 'c -
NEXTfn = let val v,s = t 'b - 'd -
val v',s' = t' 'c - 'd - 'e -
in 'e stream - 'a * 'a stream -
f v v', merge f s s' 'a - 'a stream = fn
Looking at the type inferred for sys we can see that
fun gobble g s = the typechecker has correctly inferred the various argu-
NEXTfn = let val v,s = g s ment result agreements that are required in the archi-
in tecture. For example, the output of the gob node must
v,gobble g s agree with the input to the gen node.
If we choose to specialise the architecture by provid-
fun sys gen p1 p2 fm gob init = ing some interpretation for the functions at the node
let then the type systems ensure the specialisations. For
fun f i = example, if we choose to implement fm as pairing and
let val s0 = gob as the identity then we require that the input to
filter gen gen is a pair:
NEXTfn = i,f i
val s1 = filter p1 s0 fun specsys gen p1 p2 init =
val s2 = filter p2 s0 let fun fm a b = a,b
val s3 = merge fm s1 s2 fun gob NEXT t = t
gobble gob s3 sys gen p1 p2 fm gob init
in The type inferred for the specialised system carries this
f init information:
val specsys :
The function sys describes the architecture. Notice that 'a * 'b - 'c -
the functions associated with each of the nodes in the 'c - 'a -
architecture are parameters to the function so that this 'c - 'b -
'a * 'b - 'a * 'b stream = fn fun
p2 a = a
gen a = a
It is quite possible to make incorrect re nements of the fun
fm a b = a,b
architecture. For example, if we make p1 the identity in fun
gob NEXT t =
the previous system then we end up with a contradiction let val a,_,t = t
which is detected as an occurs check problem during in a,t end
uni cation. in
sys gen p1 p2 fm gob init
fun syserr p2 init = end
let fun p1 a = a
fun gen a = a has type 'a - 'a stream. To test the function we do
fun fm a b = a,b not need to consider more than one input because the
fun gob NEXT t = t behaviour is identical for all possible values. Wherever
in we see type variables we can test with the unit type.
sys gen p1 p2 fm gob init This can bring a signi cant reduction in the e ort re-
end quired to test some architecture.
1.2 Extensions to the Type System
Function applied to argument of wrong type
Near: sys gen p1 p2 fm gob The basic ML typesystem has been extended in a variety
Required argument type: of ways. For example, the treatment of equality in SML
'b * 'a stream - has led to an extension of the type system to keep track
'b * 'b * 'a stream of those variables that are tested for equality. More
Actual argument type: recently Wadler 7 has developed a linear type system
'b * 'a stream - that detects those values that are used only once in the
'b * 'a * 'b * 'a stream course of a computation. It may be that knowing facts
Circular type results from unifying like these can help in testing programs.
'b 2 SML Modules: Typed Interfaces
'b * 'a In the SML module system we manipulate structures.
These are collections of constructs in the language. The
We know that types catch a signi cant number of pro- contents of structures are described by signatures sig-
gramming errors and that polymorphic types capture natures are rather like types for structures and functors
parametric generality. If architectures are generic in are typed maps from structures to structures. This ap-
this sense it seems that languages with parametric poly- proach leads to a style of system construction where all
morphism and type inference could capture some as- the module interfaces are well documented by signatures
pects of generic architectures. that documentation can be augmented with axioms in
the Extended ML speci cation language 5 . The ex-
1.1 Implications for Testing ample below illustrates the avour of the approach. For
The main motivation for this discussion of parametric a fuller account of the use of Modules as an architecture
polymorphism is in the context of architecture testing. implementation language see 4 .
If we believe that architectures can be generic, then
those architectures may have polymorphic types that datatype 'a,'b Filter =
capture generic operations. If a parameter to a func- WAITIN of 'a - 'a,'bFilter |
tion is allocated a type variable by the typechecker then WAITOUT of 'b * 'a,'bFilter |
that data is not subjected to inspection by the function. READY of unit - 'a,'bFilter
The appearance of such polymorphism means we have
no need to test polymorphic values with an extensive signature FILTER =
test set. If the function works for one value of a poly- sig
morphic argument it will work for all possible values type Messin
see 6 . type Messout
For example, the function:
val filter: Messin,MessoutFilter
fun systest init = end;
let fun p1 a = a
functor Pipestructure A: FILTER Ambient Global ComputationAs we move to an envir-
structure B: FILTER onment where computational services are o ered
sharing type A.Messout = B.Messin on a global scale we need to nd ways to trust and
: FILTER = test systems whose functionality we do not com-
struct pletely control and about which we may have less
type Messin = A.Messin than complete information for an introduction see
type Messout = B.Messout 9.
val filter = 3 Conclusions
let fun pipeREADY f,x = pipef,x
| pipex,READY g = pipex,g I believe that the interaction between modern type sys-
| pipeWAITOUTmo,fa,WAITIN g = tems, software architectures and testing could be fruit-
pipefa,g mo ful. I hope this paper provides some justi cation for
| pipex,WAITOUTmo,fb = that belief.
READYfn = pipex,fb
| pipeWAITIN f,fb = 1 L. Cardelli. Type Systems Available at:
WAITINfn mi = pipef mi,fb http: research.microsoft.com research
in cambridge luca Papers TypeSystems.pdf
end 2 R. J. Allen. A Formal Approach to Software
end; Architecture CMU-CS-97-144
3 R. Milner, M. Tofte and R. Harper. The De nition
2.1 A Small Experiment of Standard ML MIT Press, 1989.
Recently we have been carrying out some small exper- 4 E. Biagioni, R. Harper and P. Lee. Implementing
iments into the utility of the typed interfaces in the Software Architectures in Standard ML Proc.
Module system as a basis for integration testing. Us- ACM ICSE 17
ing a type-driven test case generator and working from
an outline proof of correctness of an Extended ML spe- 5 D. Sannella. Formal Program Development in Exten-
ci cation we considered the adequacy of the test cases ded ML for the Working Programmer, LFCS Report
generated using only the interface speci cation. ECS-LFCS-89-102, 1989.
So far we do not have enough data to make any conclus- 6 P. Wadler. Theorems for free! 4th International
ive claims but it does appear that using the interface to Conference on Functional Programming and Com-
generate test cases does uncover errors in components puter Architecture, London, September 1989.
that have been in widespread use. The reasons seem 7 P. Wadler. Linear types can change the world!
fairly clear, the approach of using the signature to gen- In M. Broy and C. Jones, editors, Programming
erate test cases results in cases that are outside the nor- Concepts and Methods, Sea of Galilee, Israel, April
mal operating range of the component and thus these 1990. North Holland, Amsterdam, 1990.
cases have never been exercised.
2.2 Further Developments 8 C. Russo. Types for Modules LFCS Thesis 1998.
The study of type systems for modules is an active area 9 L. Cardelli. Global Computation Available at:
of research. For an up-to-date survey and some inter- http: research.microsoft.com research
esting new results see 8 . cambridge luca Papers GlobalComputation.html
Higher Order Functors Here we allow functors to take
functors as parameters, the result is a more ex-
pressive system with the possibility of building con-
nector combinators in a convenient way.
First Class Structures This would allow a mixing of the
core and module level. This could provide a sound
basis for dynamic recon guration of systems.