Mary Shaw: Research Interests

[ home page] | [ software architecture publications] | [ other technical publications] |
[ educational publications] | [ nontechnical 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 systems". 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 different story.)

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:

Updated 8/15/95 by Mary Shaw
Comments to maintainer