Mary Shaw: Research Interests
home page] |
software architecture publications] |
other technical publications] |
educational publications] |
Software now accounts for the the lion's share of the cost of developing
and using computer systems. My research is directed at establishing a
genuine engineering discipline to support the design and development
of software systems. Currently I'm working on design methods, analytic
techniques, and notations for building complete software systems out of
subsystems and their constituent modules. This is the software
architecture level of design, which makes me a software architect.
Software designers often describe the architectures of their
systems by referring to common patterns such as "pipe and filter systems",
"client-server systems", "layered systems", and "object-oriented
They use box-and-line diagrams to explain the system organizations.
Most of these descriptions are highly idiosyncratic and ad hoc;
nevertheless, the designers manage to communicate.
People talk about a world in which software systems are developed by
taking components off the shelf and hooking them together, "just like
Tinkertoys". In fact, though, software components interact in many
different ways -- via procedure calls, pipes, signals, shared data, etc.
So the situation is more like grabbing parts at random from a bathtub
full of Tinkertoys, Lego blocks, Lincoln logs, Mechano parts, and so on --
then expecting them to fit together in some sensible way. (Actually,
it's more like taking parts at random from a landfill, but that's a
The Vitruvius project is developing theories, notations, and design
strategies to make good software designers' ad hoc knowledge
visible, precise, and subject to analysis.
An initial prototype, UniCon, can describe a range of systems that
rely on a variety of component interaction strategies. It can create
wrappers to convert code to support certain kinds of interactions.
We have recently reorganized it to simplify adding new connectors.
Organizing informal design guidance into well-grounded theories brings
us closer to an engineering discipline for software. We follow a strategy
of progressive codification -- we begin by capturing informal
knowledge as carefully as possible, then make the descriptions more
formal as we come to understand it better.
We want to be able to propose architectures for
software in terms that other software engineers found comprehensible; we
want to compare software organizations on an analytic basis; we want to convey
knowledge of software structures more effectively to a maintainer or
developer. In short, we could reuse knowledge of software organizations and
particular software artifacts in reasonable ways.
Examples of research questions that interest me include:
- Notations and tools for software architecture:
Identify or develop notations that are appropriate for describing system
construction from components. What are the primitive elements and operations?
What are the useful abstractions? What is the analog of the abstract-data-type
abstraction function, which demonstrates that a component implements the
interface abstraction it specifies?
- Taxonomy of styles and elements:
Develop classifications of architectural styles and of the components
and connectors that are used to create systems in these styles.
Find ways to identify components that are used in mismatched ways
and to correct the mismatch if possible.
- Consistency of views:
When multiple different views (e.g., data flow and state transtions) are
used in a design, how do you check their consistency?
Architectural definitions may specify incompatible combinations of components.
For example, the unix sort filter computes "the same" thing as the system
call, but the two are not interchangeable.
Check the definitions for consistency (under whatever specifications are
provided). When inconsistencie are found, reconcile them if possible or
report detailed nature of mismatch.
- Design guidance:
Organize information about a class of systems to help the software developer
make design decisions. Usually there are multiple architectural alternatives;
how do you choose among them? How does information about the application
you're constructing influence the design decisions?
- Partial, incremental specifications:
Conventional doctrine says that specifications are fixed, complete, and
homogeneous -- they capture eveything there is to know about a component.
In fact, however, they are intrinsically incomplete: you can't
anticipate every property another component might depend on. They are
incremental: as you learn more about a component, you must captuer it.
And they are heterogeneous: different properties require different notations.
How do notations and tools have to change to cope with the difference
between doctrine and reality?
- Establish analysis techniques:
Identify properties such as system throughput that are appropriately
specified and analyzed at the architectural level rather than the
individual-component level. How do you specify and analyze them? How
do you derive specifications for individual components that guarantee
the system properties?
- Evaluate usability:
Determine how useful the prototype system is for software designers.
Updated 8/15/95 by
Comments to maintainer