Wiki As Pattern Language
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Patterns Senior Member of Technical Staff and Pattern Languages Knowledge Systems Corp
Kyle Brown An Introduction to Patterns Senior Member of Technical Staff and Pattern Languages Knowledge Systems Corp. 4001 Weston Parkway CSC591O Cary, North Carolina 27513-2303 April 7-9, 1997 919-481-4000 Raleigh, NC [email protected] http://www.ksccary.com Copyright (C) 1996, Kyle Brown, Bobby Woolf, and 1 2 Knowledge Systems Corp. All rights reserved. Overview Bobby Woolf Senior Member of Technical Staff O Patterns Knowledge Systems Corp. O Software Patterns 4001 Weston Parkway O Design Patterns Cary, North Carolina 27513-2303 O Architectural Patterns 919-481-4000 O Pattern Catalogs [email protected] O Pattern Languages http://www.ksccary.com 3 4 Patterns -- Why? Patterns -- Why? !@#$ O Learning software development is hard » Lots of new concepts O Must be some way to » Hard to distinguish good communicate better ideas from bad ones » Allow us to concentrate O Languages and on the problem frameworks are very O Patterns can provide the complex answer » Too much to explain » Much of their structure is incidental to our problem 5 6 Patterns -- What? Patterns -- Parts O Patterns are made up of four main parts O What is a pattern? » Title -- the name of the pattern » A solution to a problem in a context » Problem -- a statement of what the pattern solves » A structured way of representing design » Context -- a discussion of the constraints and information in prose and diagrams forces on the problem »A way of communicating design information from an expert to a novice » Solution -- a description of how to solve the problem » Generative: -
Capturing Interactions in Architectural Patterns
Capturing Interactions in Architectural Patterns Dharmendra K Yadav Rushikesh K Joshi Department of Computer Science and Engineering Department of Computer Science and Engineering Indian Institute of Technology Bombay Indian Institute of Technology Bombay Powai, Mumbai 400076, India Powai, Mumbai 400076, India Email: [email protected] Email: [email protected] TABLE I Abstract—Patterns of software architecture help in describing ASUMMARY OF CCS COMBINATORS structural and functional properties of the system in terms of smaller components. The emphasis of this work is on capturing P rimitives & Descriptions Architectural the aspects of pattern descriptions and the properties of inter- Examples Significance component interactions including non-deterministic behavior. Prefix (.) Action sequence intra-component Through these descriptions we capture structural and behavioral p1.p2 sequential flow specifications as well as properties against which the specifications Summation (+) Nondeterminism choice within a component are verified. The patterns covered in this paper are variants of A1 + A2 Proxy, Chain, MVC, Acceptor-Connector, Publisher-Subscriber Composition (|) Connect matching multiple connected and Dinning Philosopher patterns. While the machines are CCS- A1 | A2 i/o ports in assembly components based, the properties have been described in Modal µ-Calculus. Restriction (\) Hiding ports from Internal The approach serves as a framework for precise architectural A\{p1, k1, ..} further composition features descriptions. Relabeling ([]) Renaming of ports syntactic renaming A[new/old, ..] I. INTRODUCTION In component/connector based architectural descriptions [6], [13], components are primary entities having identities in the represents interface points as ports uses a subset of CSP for system and connectors provide the means for communication it’s formal semantics. -
Enterprise Integration Patterns Introduction
Enterprise Integration Patterns Gregor Hohpe Sr. Architect, ThoughtWorks [email protected] July 23, 2002 Introduction Integration of applications and business processes is a top priority for many enterprises today. Requirements for improved customer service or self-service, rapidly changing business environments and support for mergers and acquisitions are major drivers for increased integration between existing “stovepipe” systems. Very few new business applications are being developed or deployed without a major focus on integration, essentially making integratability a defining quality of enterprise applications. Many different tools and technologies are available in the marketplace to address the inevitable complexities of integrating disparate systems. Enterprise Application Integration (EAI) tool suites offer proprietary messaging mechanisms, enriched with powerful tools for metadata management, visual editing of data transformations and a series of adapters for various popular business applications. Newer technologies such as the JMS specification and Web Services standards have intensified the focus on integration technologies and best practices. Architecting an integration solution is a complex task. There are many conflicting drivers and even more possible ‘right’ solutions. Whether the architecture was in fact a good choice usually is not known until many months or even years later, when inevitable changes and additions put the original architecture to test. There is no cookbook for enterprise integration solutions. Most integration vendors provide methodologies and best practices, but these instructions tend to be very much geared towards the vendor-provided tool set and often lack treatment of the bigger picture, including underlying guidelines and principles. As a result, successful enterprise integration architects tend to be few and far in between and have usually acquired their knowledge the hard way. -
From a Pattern Language to a Field of Centers and Beyond Patterns and Centers, Innovation, Improvisation, and Creativity
From a Pattern Language to a Field of Centers and Beyond Patterns and Centers, Innovation, Improvisation, and Creativity Hajo Neis Illustration 1: University of Oregon in Portland Downtown Urban Campus The Campus is located in downtown Portland in adapted old warehouse buildings, and was first designed in the Oregon pattern language method with the principles of pat- terns and user participation. The White Stag building facilities are open since 2009. 144 Hajo Neis INTRODUCTION What we call now the ›overall pattern language approach‹ in architecture, urban design, and planning has grown from its original principle of ›pattern and pat- tern language‹ into a large and solid body of theory and professional work. To- day, pattern theory and practice includes a large number of principles, methods, techniques and practical project applications in which patterns themselves play a specific part within this larger body of knowledge. Not only has the pattern lan- guage approach grown in its original area of architecture, but it has also (though less triumphantly than silently) expanded into a large number of other disciplines and fields, in particular computer and software science, education, biology, com- munity psychology, and numerous practical fields. Nevertheless, we first have to acknowledge that the pattern approach originally started with a single principle almost 50 years ago, the principle of pattern and pattern language that gave the name to this school of thought and practical professional project work. In this article we want to trace some of the theoretical and practical develop- ment of the pattern method and its realization in practical projects. We want to explore how challenges and opportunities resulted in the adaptation of the pattern language method into various forms of pattern project formats and formulations including ›pattern language‹ and ›project language.‹ We want to look at various forms of innovations and techniques that deal with theoretical improvements as well as the necessities of adaptation for practical cases and projects. -
A Survey of Architectural Styles.V4
Survey of Architectural Styles Alexander Bird, Bianca Esguerra, Jack Li Liu, Vergil Marana, Jack Kha Nguyen, Neil Oluwagbeminiyi Okikiolu, Navid Pourmantaz Department of Software Engineering University of Calgary Calgary, Canada Abstract— In software engineering, an architectural style is a and implementation; the capabilities and experience of highest-level description of an accepted solution to a common developers; and the infrastructure and organizational software problem. This paper describes and compares a selection constraints [30]. These styles are not presented as out-of-the- of nine accepted architectural styles selected by the authors and box solutions, but rather a framework within which a specific applicable in various domains. Each pattern is presented in a software design may be made. If one were to say “that cannot general sense and with a domain example, and then evaluated in be called a layered architecture because the such and such a terms of benefits and drawbacks. Then, the styles are compared layer must communicate with an object other than the layer in a condensed table of advantages and disadvantages which is above and below it” then one would have missed the point of useful both as a summary of the architectural styles as well as a architectural styles and design patterns. They are not intended tool for selecting a style to apply to a particular project. The to be definitive and final, but rather suggestive and a starting paper is written to accomplish the following purposes: (1) to give readers a general sense of several architectural styles and when point, not to be used as a rule book but rather a source of and when not to apply them, (2) to facilitate software system inspiration. -
Analysis Patterns.Pdf
Symbols for mappings DLKING , : www.dlking.com Generalization notation DLKING , : www.dlking.com Contents Foreword v Foreword vii Preface xv Chapter 1. Introduction 1 1.1 Conceptual Models 1 1.2 The World of Patterns 4 1.3 The Patterns in this Book 8 1.4 Conceptual Models and Business Process Reengineering 10 1.5 Patterns and Frameworks 11 1.6 Using the Patterns 11 References 14 Part 1. Analysis Patterns 15 Chapter 2. Accountability 17 2.1 Party 18 2.2 Organization Hierarchies 19 2.3 Organization Structure 21 2.4 Accountability 22 2.5 Accountability Knowledge Level 24 2.6 Party Type Generalizations 27 2.7 Hierarchic Accountability 28 2.8 Operating Scopes 30 2.9 Post 32 References 33 Chapter 3. Observations and Measurements 35 3.1 Quantity 36 3.2 Conversion Ratio 38 3.3 Compound Units 39 3.4 Measurement 41 3.5 Observation 42 3.6 Subtyping Observation Concepts 46 3.7 Protocol 46 3.8 Dual Time Record 47 IX DLKING , : www.dlking.com x Contents 3.9 Rejected Observation 48 3.10 Active Observation, Hypothesis, and Projection 49 3.11 Associated Observation 50 3.12 Process of Observation 51 References 55 Chapter 4. Observations for Corporate Finance 57 4.1 Enterprise Segment 59 4.2 Measurement Protocol 65 4.3 Range 76 4.4 Phenomenon with Range 77 4.5 Using the Resulting Framework 82 References 83 Chapter 5. Referring to Objects 85 5.1 Name 86 5.2 Identification Scheme 88 5.3 Object Merge 90 5.4 Object Equivalence 92 References 93 Chapter 6. -
Pedagogical and Elementary Patterns Patterns Overview
Pedagogical and Elementary Patterns Overview Patterns Joe Bergin Pace University http://csis.pace.edu/~bergin Thanks to Eugene Wallingford for some material here. Jim (Cope) Coplien also gave advice in the design. 11/26/00 1 11/26/00 2 Patterns--What they DO Where Patterns Came From • Capture Expert Practice • Christopher Alexander --A Pattern Language • Communicate Expertise to Others – Architecture • Solve Common Recurring Problems • Structural Relationships that recur in good spaces • Ward Cunningham, Kent Beck (oopsla ‘87), • Vocabulary of Solutions. Dick Gabriel, Jim Coplien, and others • Bring a set of forces/constraints into • Johnson, Gamma, Helm, and Vlisides (GOF) equilibrium • Structural Relationships that recur in good programs • Work with other patterns 11/26/00 3 11/26/00 4 Patterns Branch Out Patterns--What they ARE • Software Design Patterns (GOF...) •A Thing • Organizational Patterns (XP, SCRUM...) • A Description of a Thing • Telecommunication Patterns (Hub…) • A Description of how to Create the Thing • Pedagogical Patterns •A Solution of a Recurring Problem in a • Elementary Patterns Context – Unfortunately this “definition” is only useful if you already know what patterns are 11/26/00 5 11/26/00 6 Patterns--What they ARE (2) Elements of a Pattern • Structural relationships between •Problem components of a system that brings into • Context equilibrium a set of demands on the system •Forces • A way to generate complex (emergent) •Solution behavior from simple rules • Examples of Use (several) • A way to make the world a better place for humans -- not just developers or teachers... • Consequences and Resulting Context 11/26/00 7 11/26/00 8 Exercise Exercise • Problem: Build a stairway up a castle tower • Problem: Design the intersection of two or • Context: 12th Century Denmark. -
Pattern Languages in HCI: a Critical Review
HUMAN–COMPUTER INTERACTION, 2006, Volume 21, pp. 49–102 Copyright © 2006, Lawrence Erlbaum Associates, Inc. Pattern Languages in HCI: A Critical Review Andy Dearden Sheffield Hallam University Janet Finlay Leeds Metropolitan University ABSTRACT This article presents a critical review of patterns and pattern languages in hu- man–computer interaction (HCI). In recent years, patterns and pattern languages have received considerable attention in HCI for their potential as a means for de- veloping and communicating information and knowledge to support good de- sign. This review examines the background to patterns and pattern languages in HCI, and seeks to locate pattern languages in relation to other approaches to in- teraction 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. Andy Dearden is an interaction designer with an interest in knowledge sharing and communication in software development. He is a senior lecturer in the Com- munication and Computing Research Centre at Sheffield Hallam University. Janet Finlay is a usability researcher with an interest in design communication and systems evaluation. She is Professor of Interactive Systems in Innovation North at Leeds Metropolitan University. 50 DEARDEN AND FINLAY CONTENTS 1. INTRODUCTION 2. THE SCOPE OF THIS REVIEW 2.1. General Software Design Patterns 2.2. Interface Software Design Patterns 2.3. Interaction Design Patterns 3. A SHORT HISTORY OF PATTERNS 3.1. -
Frontiers of Pattern Language Technology
Frontiers of Pattern Language Technology Pattern Language, 1977 Network of Relationships “We need a web way of thinking.” - Jane Jacobs Herbert Simon, 1962 “The Architecture of Complexity” - nearly decomposable hierarchies (with “panarchic” connections - Holling) Christopher Alexander, 1964-5 “A city is not a tree” – its “overlaps” create clusters, or “patterns,” that can be manipulated more easily (related to Object-Oriented Programming) The surprising existing benefits of Pattern Language technology.... * “Design patterns” used as a widespread computer programming system (Mac OS, iPhone, most games, etc.) * Wiki invented by Ward Cunningham as a direct outgrowth * Direct lineage to Agile, Scrum, Extreme Programming * Pattern languages used in many other fields …. So why have they not been more infuential in the built environment??? Why have pattern languages not been more infuential in the built environment?.... * Theory 1: “Architects are just weird!” (Preference for “starchitecure,” extravagant objects, etc.) * Theory 2: The original book is too “proprietary,” not “open source” enough for extensive development and refinement * Theory 3: The software people, especially, used key strategies to make pattern languages far more useful, leading to an explosion of useful new tools and approaches …. So what can we learn from them??? * Portland, OR. Based NGO with international network of researchers * Executive director is Michael Mehaffy, student and long-time colleague of Christopher Alexander, inter-disciplinary collaborator in philosophy, sciences, public affairs, business and economics, architecture, planning * Board member is Ward Cunningham, one of the pioneers of pattern languages in software, Agile, Scrum etc., and inventor of wiki * Other board members are architects, financial experts, former students of Alexander Custom “Project Pattern Languages” (in conventional paper format) Custom “Project Pattern Languages” create the elements of a “generative code” (e.g. -
The Origins of Pattern Theory the Future of the Theory, and the Generation of a Living World
THE ORIGINS OF PATTERN THEORY THE FUTURE OF THE THEORY, AND THE GENERATION OF A LIVING WORLD Christopher Alexander Introduction by James O. Coplien nce in a great while, a great idea makes it across the boundary of one discipline to take root in another. The adoption of Christopher O Alexander’s patterns by the software community is one such event. Alexander both commands respect and inspires controversy in his own discipline; he is the author of several books with long-running publication records, the first recipient of the AIA Gold Medal for Research, a member of the Swedish Royal Academy since 1980, a member of the American Academy of Arts and Sciences, recipient of dozens of awards and honors including the Best Building in Japan award in 1985, and the American Association of Collegiate Schools of Architecture Distinguished Professor Award. It is odd that his ideas should have found a home in software, a discipline that deals not with timbers and tiles but with pure thought stuff, and with ephemeral and weightless products called programs. The software community embraced the pattern vision for its relevance to problems that had long plagued software design in general and object-oriented design in particular. September/October 1999 IEEE Software 71 Focusing on objects had caused us to lose the pattern discipline that the software community has system perspective. Preoccupation with design yet scarcely touched: the moral imperative to build method had caused us to lose the human perspec- whole systems that contribute powerfully to the tive. The curious parallels between Alexander’s quality of life, as we recognize and rise to the re- world of buildings and our world of software con- sponsibility that accompanies our position of influ- struction helped the ideas to take root and thrive in ence in the world. -
An AI Pattern Language
AN AI PATTERN LANGUAGE M.C. Elish and Tim Hwang INTELLIGENCE & AUTONOMY INITIATIVE Data & Society This publication was produced as part of the Intelligence and Autonomy initiative (I&A) at Data & Society. I&A is supported by the John D. and Catherine T. MacArthur Foundation. The Intelligence & Autonomy initiative develops research connecting the dots between robots, algorithms and automation. Our goal is to reframe policy debates around the rise of machine intelligence across sectors. For more information, visit autonomy.datasociety.net Authors: M.C. Elish and Tim Hwang Book design by Jeff Ytell and illustrations by Sarah Nicholls. Published by Data & Society, 36 West 20th Street, 11th floor, New York, NY 10011 c b a vn 10 9 8 7 6 5 4 3 2 1 ISBN-13: 978-1539033820 ISBN-10: 1539033821 CONTENTS 1 INTRODUCTION ......................................................... 1 a. Document overview ........................................... 3 b. Project background ............................................ 4 c. Methodology ..................................................... 6 d. Definitions: What do we talk about when we talk about AI? ........................ 7 i. Artificial intelligence .......................................... 8 ii. Machine learning ............................................... 9 iii. Deep learning & neural networks .................... 10 iv. Autonomy & autonomous systems .................. 11 v. Automation ..................................................... 12 vi. Machine intelligence ....................................... -
Assessing Alexander's Later Contributions to a Science of Cities
Review Assessing Alexander’s Later Contributions to a Science of Cities Michael W. Mehaffy KTH Royal Institute of Technology, 114 28 Stockholm, Sweden; mmehaff[email protected] or michael.mehaff[email protected] Received: 23 April 2019; Accepted: 28 May 2019; Published: 30 May 2019 Abstract: Christopher Alexander published his longest and arguably most philosophical work, The Nature of Order, beginning in 2003. Early criticism assessed that text to be a speculative failure; at best, unrelated to Alexander’s earlier, mathematically grounded work. On the contrary, this review presents evidence that the newer work was a logically consistent culmination of a lifelong and remarkably useful inquiry into part-whole relations—an ancient but still-relevant and even urgent topic of design, architecture, urbanism, and science. Further evidence demonstrates that Alexander’s practical contributions are remarkably prodigious beyond architecture, in fields as diverse as computer science, biology and organization theory, and that these contributions continue today. This review assesses the potential for more particular contributions to the urban professions from the later work, and specifically, to an emerging “science of cities.” It examines the practical, as well as philosophical contributions of Alexander’s proposed tools and methodologies for the design process, considering both their quantitative and qualitative aspects, and their potential compatibility with other tools and strategies now emerging from the science of cities. Finally, it highlights Alexander’s challenge to an architecture profession that seems increasingly isolated, mired in abstraction, and incapable of effectively responding to larger technological and philosophical challenges. Keywords: Christopher Alexander; The Nature of Order; pattern language; structure-preserving transformations; science of cities 1.