The essence of design is structure: What parts comprise the whole and how are they related? In the field of software, we have ways to structure implementation—with functions and datatypes, design patterns, architectures, and so on—but we lack a way to structure behavior. Witness the way we sometimes talk of having “thousands of requirements,” although a requirement is usually little more than a transition in a state machine.
To make software that is more usable and more robust, we need a way to structure behavior. Just as architects design the structure of a building in terms of light and space and flow, leaving to engineers the task of designing the physical structures that will support their visions, so we need software architects who can shape software independently of its realization.
In this talk, I'll present the elements of a new theory of software design that provides a structuring principle for behavior, criteria for identifying good and bad structures, and patterns to emulate. I'll also report on our experience applying the theory on a variety of systems.
