Type Systems, Software Architecture and Testing


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Type Systems, Software Architecture and Testing

  1. 1. 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 soa@lfcs.ed.ac.uk compare@univaq.it 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- 1 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. 1
  2. 2. ! !! gen * p1 HH H j H 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 H * S H p2 ISHH the most general possible in the sense that any other .. .. .. .. j typing of the term is obtainable by substituting some SS type for a type variable in the type. Here is the system SS response: datatype 'a stream = Figure 1: A Simple Architecture NEXT of unit - 'a * 'a stream val NEXT : unit - 'a * 'a stream - '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 end 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. end 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 in in gobble gob s3 sys gen p1 p2 fm gob init end end in The type inferred for the specialised system carries this f init information: end 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 -
  3. 3. 'a * 'b - 'a * 'b stream = fn fun p2 a = a fun 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 and '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 type UsrMess For example, the function: val filter: Messin,MessoutFilter fun systest init = end; let fun p1 a = a
  4. 4. 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. WAITOUTmo, READYfn = pipex,fb REFERENCES | 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 pipeA.filter,B.filter 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.