TL;DR: This book will enable a person to make a design for almost any kind of building, or any part of the built environment, which will replace existing ideas and practices entirely.
Abstract: You can use this book to design a house for yourself with your family; you can use it to work with your neighbors to improve your town and neighborhood; you can use it to design an office, or a workshop, or a public building. And you can use it to guide you in the actual process of construction. After a ten-year silence, Christopher Alexander and his colleagues at the Center for Environmental Structure are now publishing a major statement in the form of three books which will, in their words, "lay the basis for an entirely new approach to architecture, building and planning, which will we hope replace existing ideas and practices entirely." The three books are The Timeless Way of Building, The Oregon Experiment, and this book, A Pattern Language. At the core of these books is the idea that people should design for themselves their own houses, streets, and communities. This idea may be radical (it implies a radical transformation of the architectural profession) but it comes simply from the observation that most of the wonderful places of the world were not made by architects but by the people. At the core of the books, too, is the point that in designing their environments people always rely on certain "languages," which, like the languages we speak, allow them to articulate and communicate an infinite variety of designs within a forma system which gives them coherence. This book provides a language of this kind. It will enable a person to make a design for almost any kind of building, or any part of the built environment. "Patterns," the units of this language, are answers to design problems (How high should a window sill be? How many stories should a building have? How much space in a neighborhood should be devoted to grass and trees?). More than 250 of the patterns in this pattern language are given: each consists of a problem statement, a discussion of the problem with an illustration, and a solution. As the authors say in their introduction, many of the patterns are archetypal, so deeply rooted in the nature of things that it seemly likely that they will be a part of human nature, and human action, as much in five hundred years as they are today.
TL;DR: By fitting patterns into traditional software engineering practices, the authors of Pattern-Oriented Software Architecture successfully argue that the role for patterns will only continue to diversify and enrich tomorrow's software engineering tools and methodologies.
Abstract: Pattern-Oriented Software Architecture: A System of Patterns looks at how patterns occur on three different levels--in software architecture, in everyday design, and in idioms (which describe how a particular design pattern is implemented in a programming language like C++). This synthetic approach is a little theoretical at times, but the authors also present over a dozen patterns and provide real-world examples wherever possible. For architectural patterns, the authors look at the Layers pattern, used in operating systems such as Windows NT and virtual machines. They also consider Pipes and Filters, which process streams of data. (This pattern, the authors point out, is a lynchpin of Unix.) Their Blackboard pattern shows how a complex problem, such as image or speech recognition can be broken up into smaller, specialized subsystems that work together to solve a problem. (For recognizing words from a raw waveform input, a Blackboard approach might have separate processes to find phonemes, then words, then sentences.) This book also looks at today's distributed systems in considering the Broker pattern, which is used on the Internet and in Microsoft's OLE technology. This section also presents several powerful patterns for building effective graphical user interfaces, such as Model-View-Controller. The authors define several well-known design patterns, such as the Proxy and Command patterns, and also basic, far-reaching patterns, such as Whole-Part and Master-Slave, which are widely used throughout computing. Their survey ends with a discussion on the way objects can communicate (using such patterns as Forwarder-Receiver, Client-Dispatcher-Server, and Publisher-Subscriber), which many developers will recognize as familiar patterns, but are codified here as "official" patterns. The book then discusses some idioms in C++ and a more far-reaching role for patterns in software design and architecture. By fitting patterns into traditional software engineering practices, the authors of Pattern-Oriented Software Architecture successfully argue that the role for patterns will only continue to diversify and enrich tomorrow's software engineering tools and methodologies. --Richard Dragan
TL;DR: This paper goes back to the original conceptions of participatory design that informed Christopher Alexander's early work on patterns and pattern languages and makes connections between the technicalities of design and the central place of values.
Abstract: There is a growing demand for advice about effective, time efficient ways of using ICT to support student learning in higher education. This paper uses one such area of activity - networked learning - as a context in which to outline a novel approach to educational design. The paper makes two main contributions. It provides a high level view of the educational design problem space. It then introduces the patterns based approach to educational design. While other professional communities, particularly in software engineering, have been developing patterns based approaches to sharing and re-using design experience, this paper goes back to the original conceptions of participatory design that informed Christopher Alexander's early work on patterns and pattern languages. In particular, it makes connections between the technicalities of design and the central place of values. A patterns based approach can help with encoding, sharing and using knowledge for educational design. But it is also a powerful way of connecting educational values and vision to the details of the tasks, tools and resources we offer our students.
TL;DR: This paper shows one way to document frameworks with patterns, and includes a set of patterns for HotDraw as an example to see how well patterns work to describe a framework.
Abstract: The documentation for a framework must meet several requirements. These requirements can all be met by structuring the documentation as a set of patterns, sometimes called a “pattern language”. Patterns can describe the purpose of a framework, can let application programmers use a framework without having to understand in detail how it works, and can teach many of the design details embodied in the framework. This paper shows how to use patterns to document a framework, and includes a set of patterns for HotDraw as an example. Christopher Alexander, an architect, developed the idea of a “pattern language” to enable people to design their own homes and communities [Alexander et. al.]. A pattern language is a set of patterns, each of which describes how to solve a particular kind of problem. His pattern language starts at a very large scale, explaining how the world should be broken into nations and nations into smaller regions, and goes on to explain how to arrange roads, parking, shopping, places to work, homes, and places of worship. The patterns focus on finer and finer levels of detail, passing though a discussion of how to arrange rooms in a house, and finally describing the type of material to use for walls, how to decorate rooms, and how to provide lighting. Alexander's pattern language is supposed to be a document that non-architects can use to design their own communities and homes. No specialized training is needed to use it. It focuses on common design problems that non-architects will encounter, like how to build bedrooms and row houses, rather than uncommon ones, like how to build concert halls and cathedrals. To be presented at OOPSLA’92. Although Alexander uses the term “pattern language” to describe his document, it is not a formal language like a context-free language, for example. A pattern language is a structured essay, not a mathematical object. Therefore, we will replace that term with the term “patterns”. A framework is a reusable design of a program or a part of a program expressed as a set of classes [Deutsch][Johnson and Foote]. Like all software, it is a mixture of the concrete and the abstract. Since frameworks are reusable designs, not just code, they are more abstract than most software, which makes documenting them difficult. Frameworks are designed by experts in a particular domain and then used by non-experts. The principal audience of framework documentation is someone who wants to use the framework to solve typical problems, not someone building a software cathedral. Patterns seem to be well suited for this audience. This paper shows one way to document frameworks with patterns. It is essentially an experiment to see how well patterns work to describe a framework. The result is a set of patterns that are included in the appendix. The main purpose of a set of patterns is to show how to use a framework, not to show how it works, but patterns can also describe a great deal of the theory of its design. 1. A Format for Patterns One of the important features of Alexander’s pattern language is its structure; each pattern is written in a particular format and patterns are arranged so that each pattern leads into the next. The format that Alexander uses is unlikely to be suitable for software. For example, since he is building physical objects, he requires pictures both for stating the problem that a pattern solves and for stating the solution. Thus, the patterns in this paper have a different format that the one he used. Each pattern describes a problem that occurs over and over again in the problem domain of the framework, and then describes how to solve that problem. Each pattern has the same format. The format used in this paper is to first give a description of the problem in italics. This is followed by a detailed discussion of the different ways to solve the problem, with examples and pointers to other parts of the framework. The pattern ends with a summary of the solution, again in italics, followed by pointers to other patterns that are needed to fill it out and embellish it. The appendix to this paper describes a set of ten patterns for HotDraw, a drawing framework. For example, pattern 4 is Pattern 4: Complex Figures Some figures have a visual presentation with internal structure. For example, they may have attributes that are displayed by other figures. It should be possible to compose them from simpler figures. Complicated figures like PERTEvent can be thought of as being composed of simpler figures. For example, a PERTEvent has a RectangleFigure and several TextFigures for the title, the duration, and the ending date. Complex figures like PERTEvent are subclasses of CompositeFigure. A CompositeFigure is a figure with other figures as components, and it displays itself by displaying its components. It has a bounding box that is independent of the bounding box of its components, and it will display its components only if they are inside of its bounding box. The selection tool and text tool will operation on its components when the left shift key is pressed. Custom tools can operate directly on the components, if you want.
TL;DR: A critical review of patterns and pattern languages in human-computer interaction (HCI) seeks to locatepattern languages in relation to other approaches to interaction design, and explores four key issues.
Abstract: This article presents a critical review of patterns and pattern languages in human-computer interaction (HCI). In recent years, patterns and pattern languages have received considerable attention in HCI for their potential as a means for developing and communicating information and knowledge to support good design. This review examines the background to patterns and pattern languages in HCI, and seeks to locate pattern languages in relation to other approaches to interaction design. The review explores four key issues: What is a pattern? What is a pattern language? How are patterns and pattern languages used? and How are values reflected in the pattern-based approach to design? Following on from the review, a future research agenda is proposed for patterns and pattern languages in HCI.