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)
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,