Mary Shaw: Research Interests

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:

• 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?
• Interoperability: 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.