THIS IS AN ARCHIVED VERSION OF CRA'S WEBSITE. THIS ARCHIVE IS AVAILABLE TO PROVIDE HISTORICAL CONTENT.

PLEASE VISIT HTTP://WWW.CRA.ORG FOR THE LATEST INFORMATION

CRA Logo

About CRA
Membership
CRA for Students
CRA for Faculty
CRA-Women
Computing Community Consortium (CCC)
Awards
Projects
Events
Jobs
Government Affairs
Computing Research Policy Blog
Publications
Data & Resources
CRA Bulletin
What's New
Contact
Home

<< Back to January 2004 CRN Table of Contents

[Published originally in the January 2004 edition of Computing Research News, Vol. 16/No. 1, pp. 4, 7.]

Science of Design

By Peter A. Freeman, NSF

Efforts have been underway for many years to enable the creation of complex systems in a scientifically based manner. As we move forward into a world in which the number of devices, amount of software, and degree of connectivity in complex systems will all increase by orders of magnitude, it is essential that we have a “science of design” on which to base our efforts at building such systems. CISE is engaged in spurring the innovation and scientific development necessary to achieving this goal.


It is not news to readers of CRN that systems are difficult to create, most especially those that involve software! As the PITAC noted in its 1999 report: ". . . We have become dangerously dependent on large software systems whose behavior is not well understood and which often fail in unpredicted ways." Likewise, it is well understood that there have been many efforts over a number of years to improve this situation. For example, thirty-five years ago at the original NATO Software Engineering conference, there were strong calls to build a foundation for the systematic creation of software-intensive systems. Yet today, in spite of these efforts, we still do not have what could be called a solid scientific basis for building systems that include software elements.

Other disciplines have been working on issues of design for even longer— architecture and engineering immediately come to mind. There are areas of overlap between these other disciplines and computing, and certainly things we can learn from them. In general, however, these other disciplines do have more of a scientific basis. The design of a large building is based on many scientifically discovered and validated facts, as well as a plethora of codified experience. A similar basis exists for many engineered artifacts—chips and airplanes, for example. While not complete, these scientific bases certainly permit a degree of regularity in the process of creating them and modifying them over time that does not exist where software is involved.

Our intention at NSF is to change this situation.

It won’t happen overnight. It won’t happen before many of us have retired, but we cannot wait another thirty-five years to start to build a solid, scientific base on which complex systems involving software can be built. In this short article, I want to outline some aspects of this effort. As someone said at a recent workshop sponsored by NSF on the Science of Design, I want to talk to you about three facets: about "science," about "of," and about "design."

Let’s start with “design.” We are really concerned with all the stages of activity involved in conceptualizing, framing, implementing, commissioning, and ultimately modifying a complex system involving software—not just the stage following specification and preceding programming that might be described in an overly stylized software engineering process. “Design” is often used to designate that particular stage and that is fine, but we are using the term both more broadly and in a figurative sense. On the one hand, we are not particularly concerned with any or with all of the stages, but with the principles underlying them. On the other, and really this is the point, design is the central issue when it comes to dealing with artificial artifacts (those created by people, not naturally occurring).

The design of an artifact is the one factor or dimension that is involved, no matter what you are trying to do with or to the artifact. If you are specifying an artifact, you are shaping the design and guiding the designer to make choices that will meet the requirements for the artifact. If you are trying to build or implement an artifact, the design is your guide. If you are trying to modify an artifact, you must deal with the existing design at multiple levels. And so on.

What do we mean by “science?” A dictionary definition usually goes something like “the observation, identification, description, experimental investigation, and theoretical explanation of natural phenomena.” Of course, in talking about design, we must expand this to artificial phenomena, but that is something that (at least in computer science) we have long since come to terms with. The term “science” is used commonly to refer to a body of knowledge that is intellectually rigorous, analytic, formalized where appropriate, based on empirical studies where possible, and, above all, teachable.

In this instance, the meaning of “science” should be clear. We need to have a teachable body of knowledge with the properties noted above about complex, software-intensive systems and the processes used to create them. We have made a good start at this for some classes of algorithms, for determining how many servers may be needed to handle a given workload, and so on. But this is needed for all aspects of systems, not just isolated pieces.

Our first assertion—the centrality of design—argues for focusing there in the belief that many of the other needed principles will become easier to obtain if we have a solid basis for design. The scope of design must be much broader than the design of algorithms.

I should note explicitly that we are interested in complex systems composed of computers, software, people, and other devices. At that level, there is nothing different from the general studies of design that have been undertaken for years by other disciplines (and that are still being vigorously pursued). Yet, those other approaches to systematizing design have not solved the “software problem,” and I do not believe they will until we understand scientifically the nature of software design (both senses). Thus, we are focusing on what are sometimes called “software-intensive systems.” Such systems may very well include elements of hardware and people, and the connections to them and how to include consideration of them in the overall design of the system is, of course, critical. But the core consideration must be the software aspect.

So, we are starting from the assumption that the core issue is design in both senses of the word – (as a verb) an activity that creates a plan for an artifact and (as a noun) a plan for an artifact. “Of” then means that we are seeking a “science” that will provide a foundation for “design” in both meanings of the word.

What might a “Science of Design” include? We hope to discover the answer to this question over the next several years by supporting a wide variety of research and other activities aimed at producing a body of knowledge that is intellectually rigorous, analytic, formalized where appropriate, based on empirical studies where possible, and, above all, teachable as I noted above. Several recent workshops have already begun to shed some light on this.

Based on the thinking of the late Herb Simon as spelled out in his classic Sciences of the Artificial (MIT Press), one can imagine a science of design that includes knowledge about the generation and selection of design alternatives, design representations, solution procedures for design problems, how people design, and design structures. To elaborate only on the first of these categories, one model of the design process is that it is a process of choosing among alternative structures that go to make up the design. So, some of the questions to be answered include: How can alternative structures be generated for consideration? How can their properties be accurately described? How can we order the process of making decisions so as to minimize the time needed to obtain a satisfactory design that maximizes desired criteria?

It should be noted that this is only one model of the design process. There are others that may lead to other sets of questions. Ultimately, having a true science of design will mean that we know what those different models are and have information about the validity of each, as well as about the questions that flow from each.

I hope this short article will at least pique your interest in what we mean by “science of design.” As noted, we have already held some workshops investigating a few aspects of this extremely important topic, and you will see a program announcement very soon soliciting proposals for activities aimed at both developing a science of design and helping to frame the overall effort.

This will not be a quick process. It will require people to think about things differently and to do some new things. But without a science of design, it is very likely that we will be unable to deal with the opportunities before us.


Peter Freeman (pfreeman [at] nsf.gov) is the Assistant Director of Computer and Information Science and Engineering at the National Science Foundation.


Google
Search WWW Search cra.org

Copyright © 2007 Computing Research Association. All Rights Reserved. Questions? E-mail: webmaster@cra.org.