Department of 
Computer Science

Software Engineering Group
The Software Engineering group conducts research into collaborative development processes and tools, agile development, formal methods, systematic testing, design patterns, and support for scientific modeling and computation. (Dewan, Prins, Stotts)

Current Projects:
Distributed XP
XP is the best-known of the "agile" software development methods; its hallmark is pair programming, where two programmers develop code at a single computer. We are conducting experiments to determine if the productivity and quality gains XP brings to modest-sized projects can be sustained when development must be done across the net. We are working with programming pairs that are non-co-located, and do their joint work over the net with collaboration support tools. We are also constructing collaborative programming workstations specifically designed to enhance the impression of "being there" when programming pairs are working non-co-located.

Elemental Design Pattern Calculus
We are developing a formal system of components, or building blocks, for design patterns. Called Elemental Design Patterns (EDP), they are expressed in an object-oriented variant of the lambda calculus called rho-calculus. Once so expressed, we create expressions that combine the EDPs into larger structures. We have shown that the common OO design patterns that are in use today for software architecture are all expressible as compositions of our EDPs. Current work is in the area of tools for using the EDP calculus to find design patterns in existing code.

Informal Formal Methods: Systematic Java Testing with Axioms
XP (eXtreme Programming, due to Beck) is an agile software development process that has gained an avid following in recent years. The JUnit testing tool (also from Beck) is a freely distributed framework that supports the central XP concept of "test first" software development. JUnit is small, lightweight, easy to learn and use, and automates full regression testing of Java programs at the unit level. While JUnit provides Java classes for expressing test cases and test suites, it does not provide or proscribe per se any guidelines for deciding what test cases would be good ones for any particular class. JUnit automates the accumulation and bookkeeping required for effective regression testing, but does little to solve the traditional testing problem of selecting good test cases.

We are developing a methodology for systematically creating complete and consistent test classes for JUnit. Called JAX (for Junit Axioms), our method is based on Guttag's algebraic specification of abstract data types. A JAX-based Java class has three main software components: an algebraic specification of the required class behavior (the axioms); the related JUnit test class, structured by the axioms; and the Java implementation of the class itself. JAX can be used two ways:

  • manually, where engineers gain the advantages of our systematic approach and formalisms without having to write formal specifications directly; and
  • automated, in which engineers write formal specifications of class semantics and have translation tools generate JAX test suites from the specs.

The manual application specifically is an instance of what we call "informal formal methods." One can gain the advantages of formal approaches without having to use full formalisms. Early results have so far verified that JAX-generated test suites find more errors than ones produced non-systematically for the same target code.

Interoperable Scientific Models
Scientists who study the environment create mathematical models of portions of it, and solve these models to get information that will help with weather forecasting, resource allocation and use, urban and rural planning, and other societally important functions. Currently, environmental science is highly stratified. There are atmosphere modelers, soil modelers, hydrologists, groundwater modelers, marine biologists, and numerous other subdisciplines under the umbrella. Models in each area often need data from other areas; for example, to get proper results about surface water runoff for a particular region, you need rainfall data which comes from an atmosphere model. Environmental models do not interoperate well; if they do at all, it is with considerable manual effort to "knit" them together.

With support from the EPA we are developing a software framework for allowing environmental modelers to interconnect several models of different portions of the environment to make a hybrid, federated model that will give results no individual model can. In EPA terms, this is "multi-media modeling," where media are soil, air, water, sediment, rock, etc.

Horizontal Line
Department of Computer Science
The University of North Carolina at Chapel Hill

Content Manager: prins@cs.unc.edu
Server Manager: webmaster@cs.unc.edu
Last Content Review: 13 February 2002