Christopher Alexander: an Introduction for Object-Oriented Designers

ACM SIGSOFT Software Engineering Notes vol 19 no 1 Jan 1994 Page 39

Christopher Alexander: An Introduction for Object-Oriented Designers

Doug Lea* SUNY Oswego / NY CASE Center

Software developers lament "If only software engi- Quality neering could be more like X ... ", where X is any design-intensive profession with a longer and apparently Alexander's central premise, driving over thirty years of more successful history than software. It is therefore thoughts, actions, and writings, is that there is some- both comforting and troubling to discover that the same thing fundamentally wrong with twentieth century ar- fundamental philosophical, methodological, and prag- chitectural design methods and practices. In Notes, matic concerns arise in all of these Xs (see, for example, Alexander illustrates failures in the sensitivity of con- [23, 33, 43, 46, 18, 45, 48, 50]). In part because it is contemporary methods to the actual requirements and con- sidered as much artistry as engineering, writings about ditions surrounding their development. He argues that architecture have most extensively explored and argued contemporary methods fail to generate products that out the basic underpinnings of design. Even within this satisfy the true requirements placed upon them by in- context, the ideas of the architect Christopher Alexan- dividuals and society, and fail to meet the real demands der stand out as penetrating, and bear compelling im- of real users, and ultimately fail in the basic require- plications for software design. ment that design and engineering improve the human Alexander is increasingly well-known in object- condition. Problems include: oriented (OO) design circles for his influential work • Inability to balance individual, group, societal, and on "patterns". This paper considers patterns within ecological needs. a broader review of Alexander's prolific writings on design. These include core books Notes on the Synthe- • Lack of purpose, order, and human scale. sis of Form[l], The Timeless Way of Building[5], and • Aesthetic and functional failure in adapting to local A Pattern Language[4] (hereafter abbreviated as Notes, physical and social environments. Timeless, and Patterns respectively), other books based • Development of materials and standardized com- mostly on case studies[15, 3, 6, 7, 8], related articles (es- ponents that are ill suited for use in any specific pecially [2, 9]), and a collaborative biography[29]. application. This review introduces some highlights of Alexander's • Creation of artifacts that people do not like. work. The format is mainly topical, roughly in historical order, interspersed and concluded with remarks about Timeless continues this theme, opening with phe- connections to software design. It focuses on conceptual nomenologically toned essays on "the quality without issues, but omits topics (e.g., geometry and color) that a name", the possession of which is the ultimate goal seem less central to software. Some discussions are ab- of any design product. It is impossible to briefly sum- stracted and abbreviated to the point of caricature, and marize this. Alexander presents a number of partial in no case capture the poetry of Alexander's writings synonyms: freedom, life, wholeness, comfortability, and that can only be appreciated by reading the originals, or harmony. But no single term or example fully conveys the concreteness and practicality of pattern-based devel- meaning or captures the force of Alexander's writings on opment that can only be conveyed through experience. the reader, especially surrounding the human impact of design, the feelings and aesthetics of designers and users, the need for commitment by developers to obtain and *This is a work in progress. I encourage comments and reac- preserve wholeness, and its basis in the objective equi- tions; mail to dl@g. oswego, edu or Doug Lea, Computer Science, SUNY Oswego, Oswego, NY 13126 USA. Copies (ca.ps) may be librium of form. Alexander has been working for the ftp'ed from g. oswego, edu. Thanks to Richard Helm, Ralph John- past twelve years on a follow-up book, The Nature of son, and Chamond Liu for help with drafts. Order, devoted solely to this topic (see [29, 9]). ACM SIGSOFT Software Engineering Notes vol 19 no 1 Jan 1994 Page 40

Method and Structure latable as system statics versus dynamics), further op- portunities for integrating views become lost. Like an Notes is Alexander's most conventional and still most organism, a building is more than a realization of a de- frequently cited book, and most clearly reflects Alexan- sign or even of a development process. Model, process, der's formalist training. (He pursued architecture after context, and artifact are all intertwined aspects of the obtaining science and mathematics degrees. He is also same system. Artificial separations of models, phases, an artist, Turkish carpet collector, and licensed con: and roles break these connections. One consequence is tractor.) It has much in common with other works that abstract representations lose details that always on systems, de.,~ign, and engineering that appeared in end up mattering, but each time in different ways. The the late 1950s and early 1960s attempting to integrate micro-adaptations of tradition are lost, and resist model ideas from cybernetics, discrete math, and computing, validation efforts in those rare cases in which they are exuding an optimistic tone that real progress was being performed. Alexander provides examples from houses to made. kettles in which fascination with the form of detached, Notes (see also [15, 12, 40]) describes how, before oversimplified, inappropriate models leads to designs the advent of modern architectural methods, artifacts that no user would want. tended not to suffer from adaptation, quality, and us- In Notes, Alexander argues that the key to method- ability failures. 'The "unselfconsciously" constructed ar- ological continuity, integration, and unification is to tifacts of tradition are produced without the benefit of temper, or even replace intensionally defined models formal models and methods. Instead, a system of im- with reliance upon complete, extensionally-described plicit and often inflexible rules for design/construction sets of constraints, specific to each design effort. To progress in an evolutionary fashion. Over time, natural match its context, a solution must be constructed along forces cause successive artifacts to better adapt to and the intrinsic fractures of the problem space. This eco- mesh with their environments, almost always ultimately logical perspective generates design products that are finding points of equilibrium and beauty, while also re- optimally adapted to the microstructure of local condi- sulting in increasingly better rules applied by people tions and constraints, without the "requirements stress" who do not necessarily know why the rules work. characteristic of the products of classic methods. Historically, the modern "rational" design paradigm was both a contributing factor towards and a byproduct Notes includes presentation of a semiformal algorith- of the professionalization of design (see, e.g., [37, 18]). mic method that helps automate good partitioning un- Rational design is distinguished from traditional craft- der various assumptions. To use it, one first prepares an manship by its "selfconscious" separation of designs exhaustive list of functional and structural constraints. from products (or, to continue the evolutionary analogy, The major illustrations employ 33 and 141 constraints genotype from phenotype), its use of analytic models, respectively, each collected and refined over periods of and its focus on methods that anyone with sufficient for- months. The algorithm takes as input a boolean matrix mal training may apply. Analytic designers first make indicating whether any given pair of constraints interact tractable models (from simple blueprints on up) that - either positively or negatively, although concentrat- are analyzed and manipulated into a form that specifies ing on the negative since "misfits" are easier to iden- construction. tify and characterize. The method results in indications Rational design was in many ways a major advance of groupings that minimize total requirements interac- over traditional methods. However, as discussed in tion and resulting complexity. This statistical clustering Notes, the notions of analysis and synthesis are badly, algorithm arrives at subsystems by minimizing the in- and harmfully, construed in architecture and artifact de- teraction of problem requirements that each one deals sign, leading to the sterile study of methods that have no with. The goal is to mirror the micro-structure that bearing on the wast majority of artifacts actually built or each part in a well-adapted unselfconsciously designed the work involved in developing them. (Wolfe[51] pro- system would possess. This method relies upon a con- vides a breezier account of some of this territory, but sideration of all such constraints, again leading him to focusing on the schools and cults of personality found argue for empirically and experientially guided analysis. in modern architecture, that luckily have few parallels Even though exemplified with architectural artifacts, in software engineering.) Alexander's concerns and methods apply equally well The main problem lies in separating activities sur- to software systems, subsystems, objects, etc. While rounding analysis and synthesis rather than recogniz- there are many obvious differences between houses and ing their duality. While it is common to exploit the software, most are matters of degree at this level of dis- symmetries between form and function (roughly trans- cussion. Consider, for example: ACM SIGSOFT Software Engineering Notes vol 19 no 1 Jan 1994 Page 41

• Software entities engage in greater dynamic inter- Patterns action (e.g., send messages to each other). • Sometimes, describing software is the same as con- Timeless and Patterns were written as a pair, with the structing it (as in programming). former presenting rationale and method, and the latter • More of a software design is hidden from its users. concrete details. They present a fresh alternative to the • Software generally has many fewer physical con- use of standardized models and components, and ac- stralnts. centuate the philosophical, technical and social-impact • Some software requirements are allegedly more ex- differences between analytic methods and the adaptive, plicit and precise than "build a house here". open, and reflective (all in several senses) approach to design that Alexander is reaching for. None of these have much bearing on methodological is- The term pattern is a preformal construct (Alexander sues. As noted by Dasgupta[18], Alexander's early writ- does not ever provide a formal definition) describing ings on structure and method have influenced designers sets of forces in the world and relations among them. in all realms, including computer scientists ranging from In Timeless, Alexander describes common, sometimes Herbert Simon to Harlan Mills. Variants of Alexan- even universal patterns of space, of events, of human der's decomposition algorithm have been applied to OO existence, ranging across all levels of granularity. software [13]. One can find passages in standard pre- Patterns contains 253 pattern entries. Each entry sentations of OO decomposition (e.g.,[14]) that surely might be seen as an in-the-small handbook on a com- have indirect roots in this work. Although apparently mon, concrete architectural domain. Each entry links a independently conceived, Winograd & Flores[50] is es- set of forces, a configuration or family of artifacts, and a pecially close in spirit, and includes discussions that process for constructing a particular realization. Entries Alexander might have written had he been dealing with intertwine these "problem space", "solution space", and software: "construction space" issues in a simple, down-to-earth fashion, so that each may evolve concurrently when pat- Many of the problems that are popularly at- terns are used in development. tributed to "computerization" are the result of Entries have five parts: forcing our interactions into the narrow mold provided by a limited formalized domain. Name. A short familiar, descriptive name or phrase, usually more indicative of the solution than of the The most successful designs are not those that problem or context. Examples include Alcoves, try to fully model the domain in which they op- Main entrance, Public outdoor room, Parallel roads, erate, but those that are "in alignment" with Density rings, Office connections, Sequence of sit- the fundamental structure of that domain, and ting spaces, and Interior windows. that allow for modification and evolution to generate new structural coupling. ExRmple. One or more pictures, diagrams, and/or descriptions that illustrate prototypical application. These themes form a basis for most of Alexander's later writings. However, later efforts are also in large part a Context. Delineation of situations under which the response to failures in the methods and algorithms pre- pattern applies. Often includes background, dis- sented in Notes, as discovered by Alexander and others cussions of why this pattern exists, and evidence [2, 29, 33, 38, 49]. While they remain useful guides for generality. and tools, the methods encounter problems including Problem. A description of the relevant forces and con- the possibility of missing relevant constraints, assump- straints, and how they interact. In many cases, en- tions that requirements are completely knowable be- tries focus almost entirely on problem constraints forehand, ignoring the intrinsic value-ladenness of re- that a reader has probably never thought about. quirements specifications, inability to deal with relative Design and construction issues sometimes them- weights among constraints or higher-level interactions, selves form parts of the constraints. failure to accommodate the fact that design components may interact in ways that requirements do not, and in- Solution. Static relationships and dynamic rules (mi- flexibility in adapting to future constraints. These prob- croprocess) describing how to construct artifacts in lems, along with observations that people blindly follow- accord with the pattern, often listing several vari- ing such methods do not always create better products, ants and/or ways to adjust to circumstances. Solu- led to work increasingly removed from mainstream ar- tions reference and relate other higher- and lower- chitectural design practices. level patterns. ACM SIGSOFT Software Engineering Notes vol 19 no 1 Jan 1994 Page 42

But not everything of this form counts as a pattern. with a structural basis in or similarity with natural and Ideally, pattern entries have the following properties: traditionally constructed artifacts exploit well adapted partitionings of the world. Sometimes, patterns may Encapsulation., Each pattern encapsulates a well- be constructed more mechanically, by merging others defined problem/solution (cf.,[41, 42]). Patterns are in- and/or transforming them to apply to a different do- dependent, specific, and precisely formulated enough to main. And some patterns are so tied to universals that make clear when they apply and whether they capture they emerge from introspection and intuition uncontam- real problems and issues, and to ensure that each step inated by formalism. Heuristics based on participatory of synthesis results in the construction of a complete, design, introspection, linkage to existing artifacts, and recognizable entity, where each part makes sense as an social consensus all increase the likelihood of identify- in-the-small whole. ing central fixed and variable features, and play a role even when that environment is purely internal and/or artificial, but where each part helps generate a context Generativity. Each entry contains a local, self- for others. standing process prescription describing how to construct realizations. Pattern entries are written to be us- able by all development participants, not merely trained Openness. Patterns may be extended down to arbi- designers. Many patterns are unashamedly "recipes", trarily fine levels of detail. Like fractals, patterns have mirroring the "unselfconscious" procedures characteris- no top or bottom - at the lowest levels of any design ef- tic of traditional methodless construction. An expert fort, some are merely opaque and/or fluid (e.g., plaster, may still use a pattern in the same way that an expert concrete). Patterns are used in development by finding chef uses a cooking recipe - to help create a personal a collection of entries addressing the desired features of vision of a particular realization, while still maintaining the project at hand, where each of these may in turn critical ingredients and proportions. require other subpatterns. Experimentation with possible variants and examination of the relationships among Equilibrium. Each pattern identifies a solution space patterns that together form the whole add constraints, containing an invariant that minimizes conflict among adjustments and situation-specific specializations and forces and constraints. When a pattern is used in an ap- refinements. For example, while only a small set of plication, equilibrium provides a reason for each design patterns would typically apply in the design of a cer- step, traceable to situational constraints. The rationale tain housing community, each house will itself be unique that the solution meets this equilibrium may be a for- due to varying micro-patterns. Because the details of mal, theoretical derivation, an abstraction from empiri- pattern instantiations are encapsulated, they may vary cal data, observations of the pattern in naturally occur- within stated constraints. These details often do impact ring or traditional artifacts, a convincing series of exam- and further constrain those of other related patterns. ples, analysis of poor or failed solutions, or any mixture But again, this variability remains within the borders of these. Equilibrium is the structural side of optimality of higher-level constraints. notions familiar in computing, and can be just as hard to find a basis for, meet, or approximate [28]. Alexander Composibility. Patterns are hierarchically related. argues for establishment of objective equilibria based in Coarse grained patterns are layered on top of, relate, the "quality without a name" even (or especially) when and constrain fine grained ones. These relations in- surrounding aesthetic, personal, and social factors. He clude, but are not restricted to various whole-part also notes the elusiveness of this goal - artifacts more relations[16]. Most patterns are both upwardly and often than not fall to achieve this quality despite the downwardly composible, minimizing interaction with best of efforts. other patterns, making clear when two related patterns must share a third, and admitting maximal variation Abstraction. Patterns represent abstractions of em- in sub-patterns. Pattern entries are arranged conceptu- pirical experience and everyday knowledge. They are ally as a language that expresses this layering. Because general within the stated context, although not neces- the forms of patterns and their relations to others are sarily universal. (Each entry in Patterns is marked with only loosely constrained and written entirely in natu- a "universality" designation of zero to two stars.) Pat- ral language, the pattern language is merely analogous tern construction (like domain analysis[44]) is an iter- to a formal production system language, but has about ative social process collecting, sharing, and amplifying the same properties, including infinite nondeterministic distributed experience and knowledge. Also, patterns generativity. ACM SIGSOFT Software Engineering Notes vol 19 no 1 Jan 1994 Page 43

Process tion by someone impacted by the artifact is better than the alternative. Architects may reject user requests only Patterns includes brief recipe-like accounts on how to when their knowledge of local constraints is demonstra- apply and compose patterns. However, Alexander dis- bly greater. courages slavish conformance, and describes development mainly through concrete examples illustrating how groupings at different levels of hierarchies tend to be Responsibility. Architects hold financial and legal based upon different levels of concerns. Coarser-grained charge for the consequences of their activities, and con- patterns are less constraining in detail than finer- trol corresponding cash flow. This provides both au- grained ones. Exact commitments are postponed un- thority and responsibility for adaptation across devel- til the consequences of lower-level construction and/or opment. experimentation can be assessed. Even though high-level patterns hold throughout development, this process need not, for example, generate a classic blueprint drawing before construction. Also, Decentralization. Larger efforts can be subdivided because the relations among larger and smaller patterns into expanding centers or domains, that increasingly in- do not always represent strict containment, there may fluence one another in the course of growth. Localized be interactions among subpatterns and other higher- experimentation, discovery, and change are intrinsic to level interactions requiring experimentation and reso- such adaptation. This includes situations in which con- lution. Patterns includes entries (e.g., Site repair) de- ditions change and designs evolve. The diagnosis and scribing how to deal with particular kinds of interac- local repair of problems with existing parts are part of tions. All "joints", "transitions", and "spaces" among any design effort. components are explicitly designed using other patterns that balance the needs of the parts versus the needs of the whole. Integration of Roles. Designers operate at several Pattern-based design activities resist accommodation levels. Primary roles should be assigned with respect to within a linear development process, and raise chal- problem task or domain, not phase or level. Architects lenges in the construction of suitable process models must sometimes be builders, and vice versa. They can- that still meet costing, predictability, and control crite- not otherwise get things right. Intimacy with all aspects ria. Since the early 1970s Alexander has experimented of an effort allows the builder-architect to firsthand dis- with several overall development processes that preserve cover constraints, needs and desires. the integrity and promises of pattern-based design, as applied to projects at all scales, including houses, a cafe, a medical facility, apartments, two universities, Integration of Activities. Design is interwoven with a rural housing community, and an urban community synthesis in a mainly bottom-up fashion. Construction [5, 29, 3, 9, 6, 7, 8]. The resulting process principles proceeds in an order governed by pattern interdepen- and development patterns include: dencies, the continuous analysis and repair of failures, and commitment to detail, variety, experimentation, Collective Development. Development is a social and wholeness. Concurrent development of mostly- process. Participation from all levels (users, policy- independent parts allows construction to branch out makers, etc.) is required for decisions affecting multiple from multiple centers, ultimately "stiffening" into final parts or users, as well as those concerning future growth form. and evolution. Rather than a plan, a group adopts a (stateful) process that balances collective and individual needs, and preserves the rationale for particular de- Stepwise Construction. Artifacts are constructed cisions. one pattern at a time, each of which results in a complete, recognizable form adapted to other already- Participatory Design. Users can help design things constructed artifacts and partially committed plans. that they really need and want, that are better adapted Efforts are focused upon operations, not components. to their surroundings, and that are more aesthetically Each operation is complete in itself. Creativity and ac- pleasing (see also [47, 40, 34]). Even if the design partic- complishment are maintained at all levels of this pro- ipants are not the permanent, ultimate users, participa- cess. ACM SIGSOFT Software Engineering Notes vol 19 no 1 Jan 1994 Page 44

Patterns and OO Design constructs. Conversely, OO concepts may be applied to strengthen pattern-based design notions: The form and features of patterns, and the methods and processes surrounding them are in no way special to architectural design. The entries in Patterns represent Languages and Tools. Alexander grammatically ar- "special theorie~s" of the world. Alexander notes[29] that ranges pattern entries (although in an implicit fashion) his characterization of patterns meshes well with com- to exploit the generative properties of formal languages mon definitions of scientific theories. The heuristics gov- [29]. In computing, just about every possible formal, erning the cons Lruction of patterns are all but indistin- semiformal, and informal set of constructs have been guishable from those for theories. (See also [18, 49, 38], collected as a language of some sort. For example, as who note that while such correspondences add an aura shown in the Demeter project [36], a set of OO classes of respectability, they also open up design to the con- may be represented grammatically using rewrite rules troversies surrounding modern scientific method.) Pat- denoting pattern-like compositional layering. However, terns are less general than descriptions of the base se- it is unnecessary to construe a collection of patterns or mantics of the pattern language itself, yet equally far classes themselves as a language. In programming, it removed from the realm of "neat tricks". The careful is usually more convenient to express descriptions in a interplay betwe,en contexts, problem-space forces, and broader language, to facilitate manipulation, compila- constructive solutions make this framework an ideal ba- tion, etc. Extensions of OO modelling, design and/or sis for capturing other kinds of design knowledge and programming languages may serve well in representing practices as well. patterns. Such formalization also allows for construc- In fact, Alexander's patterns bear a straightforward tion of design tools. Several Computer Aided Architec- relation to OO constructs. Patterns may be viewed as tural Design (CAAD) systems have represented Alexan- extending the definitional features of classes. In OO der's patterns in software. Most recently, Galle [24, 25] design, classes have two principle aspects, analogous to has described a CAAD framework supporting pattern- those of patterns: based design built as a partially object-oriented expert system. Aspects of this system might be abstracted as • The external, problem-space view: Descriptions of patterns, and used in the construction of similar CASE properties, responsibilities, capabilities and sup- design tools. However, it will surely take some time be- ported services as seen by software clients or the fore OO design tools and books reach the utility and outside world. authoritativeness of Patterns. • The internal, solution-space view: Static and dynamic descriptions, constraints, and contracts among other components, delegates, collaborators Subelassing and Refinement. In addition to sup- and helpers, each of which is known only with re- porting compositional relations, all OO notations in- spect to a possibly incomplete external view (i.e., clude a second kind of structuring rule to describe pos- a class, but where the actual member may conform sible alternative paths though a set of concepts, cap- to a stronger subclass). turing both the composition / decomposition and abstraction / refinement design spectra within a linguistic The best classes, also share the properties of appropri- framework. OO methods and languages thus add a new ate abstraction, encapsulation, openness, and equilib- set of concepts to this aspect of Alexander's framework. rium. Like patterns, classes are normally generative, While the notion of variability within broad classifica- supporting parameterized instance construction as well tions permeates his writings, Alexander does not explic- as higher-order instantiation in the case of generic (tem- itly employ the idea of structured refinement through plate) classes. Classes are intrinsically composible, al- subclassing. This probably stems from the fact that though these compositions need not always be expressed there is no good reason for formalizing the concept in as classes, e.g., at topmost decomposition levels. architectural design, where there is little use in explic- Indeed, since patterns can describe concepts and itly capturing the refinements between a pattern and structures (e.g., coordinated groups) that are not them- its realization. Instead, the pattern is (often gradually) selves objects, the term pattern may be more fitting than replaced by its realization. However, in software, these class (or alternatively, the notion of a class should be intermediate forms can play all sorts of roles in devel- broadened) at least at the level of OO design variously opment, including use as branch points for alternative termed "abstracC, "architectural", and/or "functional" specializations, bases for differential design, descriptions (see., e.g., [20]). Patterns can thus raise the expressive- of common protocols in OO frameworks, and a means hess and level of description supported by familiar OO for swapping in one component for another. ACM SIGSOFT Software Engineering Notes vol 19 no 1 Jan 1994 Page 45

Inheritance and Delegation. OO design techniques ethic at the heart of pattern-based development pro- incorporating various subclassing, delegation, and com- cesses. More than anything else, experiences with OO position constructs conquer a potential obstacle found versions of patterns have been the driving force lead- in the application of pattern-based design in other ing OO researcher-practitioners to examine and exploit realms. Alexander's patterns provide a basis for de- the many relationships between the semantic bases, us- sign reuse without any necessary implications for com- ages, activities, and processes of OO and pattern-based ponent reuse, thus limiting the routine generation and development. Most work is still in the exploratory predictable use of standardized components with known phase; including reconceptualizations of basic OO tech- cost and properties, and running into quality-control niques and idioms (e.g., those found in [17, 14, 20]), OO problems intrinsic to reliance on one-shot implementa- frameworks([32]) and micro-architectures ([10, 26, 27]), tions. This is generally not the case in OO design. Even as well as the methods, processes, tools, formalizations, when an existing or standard component isn't what you development patterns, education, and social contexts want, it often happens that alternative specializations, best supporting their development. It may yet turn out delegation structures, and/or subclasses can share much that the ideas that have long isolated Alexander from code via standard OO programming tactics. In fact, the mainstream commercial architectural community[9, this happens so often that OO programmers are sur- 22] will find their widest and most enduring impact in prised, complain, and are sometimes unable to cope object-oriented software engineering. when it does not (e.g., fairly often in concurrent OO programming[39]). References

Adaptation and Reflection. Further out, OO con- [1] Alexander, C., Notes on the Synthesis of Form, cepts may also help crystalize the senses of method- Harvard University Press, 1964. ological unity, adaptation, openness, and reflection that [2] Alexander, C., "A Refutation of Design Methodol- pervade Alexander's work. The lack of a crisp distinc- ogy" (Interview with Max Jacobson), Architectural tion between software "design" and "manufacturing" Design, December, 1971. already makes development practices harder to clas- [3] Alexander, C., M. Silverstein, S. Angel, S. sify along the continuum from craftmanship to ana- Ishikawa, & D. Abrams, The Oregon Experiment, lytic engineering[34]. This becomes accentuated when Oxford University Press, 1975. software systems themselves include provisions for self- Alexander, C., S. Ishikawa, & M. Silverstein, A adaptation and redesign. So while it sounds overly [4] Pattern Language, Oxford University Press, 1977. metaphysical to, for example, view buildings as clever devices to propagate architects or blueprints (cf., [19, [5] Alexander. C., The Timeless Way of Building, Ox- 21, 49]), in software these dualities have very practical ford University Press, 1979. consequences. Work in OO and AI (e.g., [35, 31, 50, 30]) [6] Alexander. C., The Linz Care, Oxford University has led to reification and metalevel reasoning constructs Press, 1981. that, although by no means completely understood, al- [7] Alexander. C., The Production of Houses, Oxford low creation of useful systems in which the borderlines University Press, 1985. between designer, model, design, and product nearly [s] Alexander C., A New Theory of Urban Design, Ox- vanish, as is necessary for example in computer as- ford University Press, 1987. sisted manufacturing (CAD/CAM/CIM)[ll], where the [9] Alexander C., "Perspectives: Manifesto 1991", market-driven trend has been to move away from sys- Progressive Architecture, July 1991. tems that merely increase productivity or reduce defects [10] Anderson B., & P. Coad (Organizers), "Patterns in mass-produced products. Instead, systems must rely Workshop", OOPSLA '93. on both adaptive development methods and adaptive [11] Ayers, R., & D. Butcher, "The Flexible Factory Re- software mechanisms to enable the reconfigurability re- visited", American Scientist, September-October quired to obtain flexibility and user-perceived quality in 1993. manufacturing small runs. [12] Basalla, G., The Evolution of Technology, Cam- bridge University Press, 1988. Process Integration. While OO process models re- [131 Bonine, J., "A Theory of Software Architecture De- main underdeveloped, their potential synergy with sign", unpublished draft manuscript, 1993. pattern-based models is obvious. The average OO devel- [14] Booth, G., Object Oriented Design with Applica- oper personifies the builder-architect (hacker-designer?) tions, 2nd ed., Benjamin Cummings, 1993. ACM SIGSOFT Softwaxe Engineering Notes vol 19 no 1 Jan 1994 Page 46

[15] Chermayetf, S., & C. Alexander, Community and [34] Karat, J. (ed), Taking Software Design Seriously: Privacy: 7bward a New Architecture of Humanism, Practical Techniques for Human-Computer Inter- Doubleday, 1963. action Design, Academic Press, 1991. [16] Civello, F., "Roles for Composite Objects in Ob- [35] Kiczales, G., J. des Rivieres, & D.G. Bobrow, The ject Oriented Analysis and Design", Proceedings, Art of the Metaobject Protocol, MIT Press, 1991. OOPSLA '93, ACM, 1993. [36] Lieberherr, K. & I. Holland, "Assuring Good Style [17] Coplien, J., Advanced C-t-+: Programming Styles for Object-Oriented Programs", IEEE Software, and Idioms, Addison-Wesley, 1991. September 1989. [18] Dasgupta, S., Design Theory and Computer Sci- [37] Lucie-Smith, B., A History of Industrial Design, ence, Cambridge University Press, 1991. Van Nostrand, 1983. [19] Dawkins, R., The Selfish Gene, Oxford University [38] March, L. (ed), The Architecture of Form, Cam- Press, 1976. bridge University Press, 1976. [20] de Champeaux, D., D. Lea, & P. Faure, Object Ori- [39] Matsuoka, S., K. Taura, & A. Yonezawa, "Highly ented System Development, Addison-Wesley, 1993. Efficient and Encapsulated Reuse of Synchroniza- tion Code in Concurrent Object-Oriented Lan- [21] Dennett, D., The Intentional Stance, Bradford guages", Proceedings, OOPSLA '93, ACM, 1993. Books, 1987. [40] Norman, D., The Psychology of Everyday Things, [22] Dovey, K., "The Pattern Language and its Ene- Basic Books, 1988. mies". Design Studies, vol 11, p3-9, 1990. [41] Parnas, D., "On the Criteria to be Used in the De- [23] French, M. J., Invention and Evolution: Design in composition of Systems into Modules", Communi- Nature and Engineering. Cambridge, 1988. cations of the ACM, December, 1972. [24] Galle, P., "Alexander Patterns for Design Comput- [42] Parnas, D., "Designing Software for Ease of Exten- ing: Atoms of Conceptual Structure?" Environ- sion and Contraction" 1EEE Transactions on Soft- ment and Planning B: Planning and Design, vol ware Engineering, March 1979. 18, p327-346, 1991. [43] Petroski, H., To Engineer is Human. St. Martin's [25] Galle, P., "Computer Support of Architectural Press, 1982. Sketch Design: A Matter of Simplicity?" Environ- [44] Prieto-Diaz, R., & G. Arango (eds.), Domain Anal- ment and Planning B: Planning and Design, vol ysis: Acquisition of Reusable Information for Soft- 21, 1994. ware Construction, IEEE Computer Society Press, [26] Gamma, E., R. Helm, R. Johnson, & J. Vlis- 1989. sides, "Design Patterns: Abstraction and Reuse [45] Rowe, P., Design Thinking. MIT Press, 1987. of Object-Oriented Designs", Proceedings, ECOOP [46] Sch5n, D., Educating the Reflective Practitioner, '93, Springer-Verlag, 1993. Jossey-Bass, 1987. [27] Gamma, E., R. Helm, R. Johnson, & J. Vlissides, [47] Schuler, D., & A. Namioka, Participatory Design, • Design Pat.terns, Addison-Wesley, forthcoming. Lawrence Erlbaum, 1993. [28] Garey, M. & D. Johnson, Computers and In- [48] Simon, H., The Sciences of the Artificial, MIT tractability, Freeman, 1979. Press, 1981. [29] Grabow, S., Christopher Alexander: The Search for [49] Steadman, P., The Evolution of Designs, Cam- a New Paradigm, Oriel Press, 1983. bridge University Press, 1979. [30] Hamilton, G., M. Powell, & J. Mitchell. Subcon- [50] Winograd, T., & F. Flores, understanding Com- tract: A Flexible Base for Distributed Program- puters and Cognition: A New Foundation for De- ming. Sun Microsystems Laboratories Technical sign, Addison-Wesley, 1986. Report Tlq;-93-13, 1993. [51] Wolfe, T., From Our House to Bauhaus, Pocket [31] Hewitt, C., P, Bishop, & R. Steiger, "A Univer- Books, 1981. sal Modular ACTOR Formalism for AI", Third In- ternational Joint Conference on Artificial Intelli- gence, Stanford University, August 1973. [32] Johnson, R., "Documenting Frameworks Using Patterns", Proceedings, OOPSLA 92, ACM, 1992. [33] Jones, J. C., Design Methods, 2nd ed., Van Nos- trand, 199'2.