Pattern-Oriented Software Architecture Frank Buschmann Kevlin Henney

Total Page:16

File Type:pdf, Size:1020Kb

Pattern-Oriented Software Architecture Frank Buschmann Kevlin Henney Mo 2 January 21-25, 2008, Munich, Germany ICM - International Congress Centre Munich Pattern-Oriented Software Architecture Frank Buschmann Kevlin Henney Pattern-Oriented Software Architecture T H E C R A F T O F S O F TT F TO F R E W H E C R R C H I O F S A A A TT E C U R E Kevlin Henney Frank Buschmann Curbralan Limited Siemens AG [email protected] [email protected] Agenda Introduction Stand-Alone Patterns Pattern Complements / Pattern Compounds Pattern Stories / Pattern Sequences Pattern Languages P A T E R N –P A RE C H I T E U R R E A W A E D S O F T R I E N T O Outroduction References Pattern-Oriented Software Architecture 2 © Frank Buschmann, Kevlin Henney, all rights reserved 1 Where we are Introduction Stand-Alone Patterns Pattern Complements / Pattern Compounds Pattern Stories / Pattern Sequences Pattern Languages P A T E R N –P A RE C H I T E U R R E A W A E D S O F T R I E N T O Outroduction References Pattern-Oriented Software Architecture 3 © Frank Buschmann, Kevlin Henney, all rights reserved On Designing with Patterns (1) Patterns have become a popular tool in software design … • They have changed the way software developers think about and practice software design • They provide us with a software design vocabulary • They help us to resolve recurring problems constructively and based on proven solutions • They support us in understanding the architecture of a given software system • ... P A T E R N –P A RE C H I T E U R R E A W A E D S O F T R I E N T O But: applying patterns in software design is not necessarily designing with patterns! Pattern-Oriented Software Architecture 4 © Frank Buschmann, Kevlin Henney, all rights reserved 2 On Designing with Patterns (2) Patterns applied in isolation and as modular building blocks do not create sustainable designs. Command Processor Solutions Command Logging Logging Client • Fail to consider the surrounding Processor Context Strategy problems and their solutions. Concrete Component * Logging • Have at best only local effects. Strategy Composite • Do not complement one another Strategy or mutually reinforce their Leaf Compositen sig De beneficial properties. or Po Memento P A T E R N –P A RE C H I T E U R R E A W A E D S O F T R I E N T O • Create complex architectures Command Caretaker that lack useful operational and developmental qualities. Concrete Concrete Memento Command Command Command Application Pattern-Oriented Software Architecture 5 © Frank Buschmann, Kevlin Henney, all rights reserved On Designing with Patterns (3) There are two fundamental ways of integrating patterns: • Refinement: One pattern refines the structure and behavior of another pattern to address a specific sub-problem or implementation detail. • Combination: Two or more patterns arranged to form a larger structure that addresses a more complex problem. There are also relationships regarding choice: • Alternatives: Some patterns describe alternatives to one another. They address the same or a similar problem, but each pattern considers a slightly P A T E R N –P A RE C H I T E U R R E A W A E D S O F T R I E N T O different set of forces. Thus, the patterns provide different solutions and have different consequences. • Cooperation: Some patterns nicely complement one another, mutually reinforcing their structural and behavioral properties. Pattern-Oriented Software Architecture 6 © Frank Buschmann, Kevlin Henney, all rights reserved 3 On Designing with Patterns (4) Patterns applied by considering their relationships create balanced designs. Command Processor Strategy Solutions Command Logging Client • Consider their surrounding Processor Strategy problem and solution space. Concrete gn Logging • Have systemic effects. si Strategy Command & De Composite od • Complement one another Go Command Memento and mutually reinforce their * beneficial properties. Memento P A T E R N –P A RE C H I T E U R R E A W A E D S O F T R I E N T O • Create whole and balanced Concrete Composite Command Command designs that expose the required operational and developmental qualities. Application Pattern-Oriented Software Architecture 7 © Frank Buschmann, Kevlin Henney, all rights reserved On Designing with Patterns (5) This tutorial is on designing with The network patterns to create, Telegram Telegram with economy and elegance, Forwarder Receiver passes telegrams to passes telegrams to software designs and Telegram passes Converter commands to implementations applies Command Logging Logger Processor Strategy that work and meet their executes Log expected quality attributes! Command creates Alarms Pick SetPoint Workpiece Calculation P A T E R N –P A RE C H I T E U R R E A W A E D S O F T R I E N T O Pattern-Oriented Software Architecture 8 © Frank Buschmann, Kevlin Henney, all rights reserved 4 Where we are Introduction Stand-Alone Patterns Pattern Complements / Pattern Compounds Pattern Stories / Pattern Sequences Pattern Languages P A T E R N –P A RE C H I T E U R R E A W A E D S O F T R I E N T O Outroduction References Pattern-Oriented Software Architecture 9 © Frank Buschmann, Kevlin Henney, all rights reserved A Solution to a Problem (1) A stand-alone pattern: • Presents a solution for a recurring problem that arises in a specific context. • Documents proven design experience; is an "aggressive disregard of originality" Brian Foote • Specifies a spatial configuration of elements and the behavior that happens in this configuration. • Provides common vocabulary and conceptual understanding. P A T E R N –P A RE C H I T E U R R E A W A E D S O F T R I E N T O Pattern-Oriented Software Architecture 10 © Frank Buschmann, Kevlin Henney, all rights reserved 5 Half-Object Plus Protocol at a Glance Problem Half Objects How can we design objects in a Node 1 Node 2 distributed system: local • such that access to them and the execution of their services incurs minimal performance penalties? remote Solution • Split an object into multiple halves – Client Protocol P A T E R N –P A RE C H I T E U R R E A W A E D S O F T R I E N T O one half per address space from which the object is accessed. • Within each half, fully implement all functionality that can be executed locally without using the network. • Implement functionality that crosses address spaces partially in each half and coordinate the halves via a protocol. Pattern-Oriented Software Architecture 11 © Frank Buschmann, Kevlin Henney, all rights reserved A Solution to a Problem (2) A stand-alone pattern: • Is both a process and a thing, with the thing being created by the process. • Addresses a set of forces that completes the general problem by describing requirements, constraints, and desired properties for the solution. • Introduces a set of interacting roles that can be arranged in many different ways, not a fixed configuration of classes or components. P A T E R N –P A RE C H I T E U R R E A W A E D S O F T R I E N T O • Specifies a solution that is based on experience, judgment, and diligence – it cannot necessarily be constructed in a straightforward manner using a common engineering method. Pattern-Oriented Software Architecture 12 © Frank Buschmann, Kevlin Henney, all rights reserved 6 Half-Object Plus Protocol at a Glance (2) Problem Role: Half Objects Force How can we design objects in a Node 1 Node 2 distributed system: local • such that access to them and the execution of their services incurs minimal performance penalties? remote Solution Role: Client Role: Protocol • Split an object into multiple halves – P A T E R N –P A RE C H I T E U R R E A W A E D S O F T R I E N T O one half per address space from which the object is accessed. Process- oriented • Within each half, implement all functionality that solution can be executed locally without using the network. • Implement functionality that crosses address spaces partially in each half and coordinate the halves via a protocol. Pattern-Oriented Software Architecture 13 © Frank Buschmann, Kevlin Henney, all rights reserved Designing with Stand-Alone Patterns Stand-alone patterns can help you to resolve specific, restricted problems well, but • They discuss the solution they introduce in isolation from other problems and their solutions, and also the dependencies between the problems and solutions. • They do not consider alternative solutions to similar problems but with different sets of forces. • They do not inform you when to address the problem in the context of designing a concrete system that must resolve many different problems. P A T E R N –P A RE C H I T E U R R E A W A E D S O F T R I E N T O Patterns are like colorful words, bits and pieces of an expressive language whose grammar is forgotten and whose exciting stories and cultural tales are lost! Pattern-Oriented Software Architecture 14 © Frank Buschmann, Kevlin Henney, all rights reserved 7 Where we are Introduction Stand-Alone Patterns Pattern Complements / Pattern Compounds Pattern Stories / Pattern Sequences Pattern Languages P A T E R N –P A RE C H I T E U R R E A W A E D S O F T R I E N T O Outroduction References Pattern-Oriented Software Architecture 15 © Frank Buschmann, Kevlin Henney, all rights reserved Pattern Complements Pattern complements are sets of patterns that are • Complementary with respect to competition.
Recommended publications
  • Neuroscience, the Natural Environment, and Building Design
    Neuroscience, the Natural Environment, and Building Design. Nikos A. Salingaros, Professor of Mathematics, University of Texas at San Antonio. Kenneth G. Masden II, Associate Professor of Architecture, University of Texas at San Antonio. Presented at the Bringing Buildings to Life Conference, Yale University, 10-12 May 2006. Chapter 5 of: Biophilic Design: The Theory, Science and Practice of Bringing Buildings to Life, edited by Stephen R. Kellert, Judith Heerwagen, and Martin Mador (John Wiley, New York, 2008), pages 59-83. Abstract: The human mind is split between genetically-structured neural systems, and an internally-generated worldview. This split occurs in a way that can elicit contradictory mental processes for our actions, and the interpretation of our environment. Part of our perceptive system looks for information, whereas another part looks for meaning, and in so doing gives rise to cultural, philosophical, and ideological constructs. Architects have come to operate in this second domain almost exclusively, effectively neglecting the first domain. By imposing an artificial meaning on the built environment, contemporary architects contradict physical and natural processes, and thus create buildings and cities that are inhuman in their form, scale, and construction. A new effort has to be made to reconnect human beings to the buildings and places they inhabit. Biophilic design, as one of the most recent and viable reconnection theories, incorporates organic life into the built environment in an essential manner. Extending this logic, the building forms, articulations, and textures could themselves follow the same geometry found in all living forms. Empirical evidence confirms that designs which connect humans to the lived experience enhance our overall sense of wellbeing, with positive and therapeutic consequences on physiology.
    [Show full text]
  • Open Source Architecture, Began in Much the Same Way As the Domus Article
    About the Authors Carlo Ratti is an architect and engineer by training. He practices in Italy and teaches at the Massachusetts Institute of Technology, where he directs the Senseable City Lab. His work has been exhibited at the Venice Biennale and MoMA in New York. Two of his projects were hailed by Time Magazine as ‘Best Invention of the Year’. He has been included in Blueprint Magazine’s ‘25 People who will Change the World of Design’ and Wired’s ‘Smart List 2012: 50 people who will change the world’. Matthew Claudel is a researcher at MIT’s Senseable City Lab. He studied architecture at Yale University, where he was awarded the 2013 Sudler Prize, Yale’s highest award for the arts. He has taught at MIT, is on the curatorial board of the Media Architecture Biennale, is an active protagonist of Hans Ulrich Obrist’s 89plus, and has presented widely as a critic, speaker, and artist in-residence. Adjunct Editors The authorship of this book was a collective endeavor. The text was developed by a team of contributing editors from the worlds of art, architecture, literature, and theory. Assaf Biderman Michele Bonino Ricky Burdett Pierre-Alain Croset Keller Easterling Giuliano da Empoli Joseph Grima N. John Habraken Alex Haw Hans Ulrich Obrist Alastair Parvin Ethel Baraona Pohl Tamar Shafrir Other titles of interest published by Thames & Hudson include: The Elements of Modern Architecture The New Autonomous House World Architecture: The Masterworks Mediterranean Modern See our websites www.thamesandhudson.com www.thamesandhudsonusa.com Contents
    [Show full text]
  • (Perry & Wolf 92) Software Architecture (Garlan & Shaw
    ICS 221, Winter 2001 Software Architecture Software Architecture (Perry & Wolf 92) “Architecture is concerned with the selection of architectural elements, their interactions, and the Software Architecture constraints on those elements and their interactions necessary to provide a framework in which to satisfy the requirements and serve as a basis for the design.” David S. Rosenblum ICS 221 “Design is concerned with the modularization and detailed interfaces of the design elements, their Winter 2001 algorithms and procedures, and the data types needed to support the architecture and to satisfy the requirements.” Software Architecture Software Architecture (Garlan & Shaw 93) (Shaw & Garlan 96) “Software architecture is a level of design that goes “The architecture of a software system defines beyond the algorithms and data structures of the that system in terms of computational computation; designing and specifying the overall components and interactions among those system structure emerges as a new kind of problem. Structural issues include gross organization and components. … In addition to specifying the global control structure; protocols for communication, structure and topology of the system, the synchronization, and data access; assignment of architecture shows the correspondence functionality to design elements; physical between the requirements and elements of distribution; composition of design elements; scaling the constructed system, thereby providing and performance; and selection among design some rationale for the design decisions.” alternatives.” Analogies with Differences Between Civil and Civil Architecture Software Architecture Civil Engineering and Civil Architecture “Software systems are like cathedrals—first we are concerned with the engineering and design of build them and then we pray.” civic structures (roads, buildings, bridges, etc.) — Sam Redwine ! Multiple views ! Civil: Artist renderings, elevations, floor plans, blueprints ! Physical vs.
    [Show full text]
  • Design Patterns Promote Reuse
    Design Patterns Promote Reuse “A pattern describes a problem that occurs often, along with a tried solution to the problem” - Christopher Alexander, 1977 • Christopher Alexander’s 253 (civil) architectural patterns range from the creation of cities (2. distribution of towns) to particular building problems (232. roof cap) • A pattern language is an organized way of tackling an architectural problem using patterns Kinds of Patterns in Software • Architectural (“macroscale”) patterns • Model-view-controller • Pipe & Filter (e.g. compiler, Unix pipeline) • Event-based (e.g. interactive game) • Layering (e.g. SaaS technology stack) • Computation patterns • Fast Fourier transform • Structured & unstructured grids • Dense linear algebra • Sparse linear algebra • GoF (Gang of Four) Patterns: structural, creational, behavior The Gang of Four (GoF) • 23 structural design patterns • description of communicating objects & classes • captures common (and successful) solution to a category of related problem instances • can be customized to solve a specific (new) problem in that category • Pattern ≠ • individual classes or libraries (list, hash, ...) • full design—more like a blueprint for a design The GoF Pattern Zoo 1. Factory 13. Observer 14. Mediator 2. Abstract factory 15. Chain of responsibility 3. Builder Creation 16. Command 4. Prototype 17. Interpreter 18. Iterator 5. Singleton/Null obj 19. Memento (memoization) 6. Adapter Behavioral 20. State 21. Strategy 7. Composite 22. Template 8. Proxy 23. Visitor Structural 9. Bridge 10. Flyweight 11.
    [Show full text]
  • Active Object Systems Redacted for Privacy Abstract Approved
    AN ABSTRACT OF THE THESIS OF Sungwoon Choi for the degree of Doctor of Philosophyin Computer Science presented on February 6, 1992. Title: Active Object Systems Redacted for Privacy Abstract approved. v '" Toshimi Minoura An active object system isa transition-based object-oriented system suitable for the design of various concurrentsystems. An AOS consists of a collection of interacting objects, where the behavior of eachobject is determined by the transition statements provided in the class of that object.A transition statement is a condition-action pair, an equational assignmentstatement, or an event routine. The transition statements provided for eachobject can access, besides the state of that object, the states of the other objectsknown to it through its interface variables. Interface variablesare bound to objects when objects are instantiated so that desired connections among objects are established. The major benefit of the AOS approach is thatan active system can be hierarchically composed from its active software componentsas if it were a hardware system. An AOS provides better encapsulation andmore flexible communication protocols than ordinary object oriented systems, since control withinan AOS is localized. ©Copyright by Sungwoon Choi February 6, 1992 All Rights Reserved Active Object Systems by Sungwoon Choi A THESIS submitted to Oregon State University in partial fulfillment of the requirements for the degree of Doctor of Philosophy Completed February 6, 1992 Commencement June 1992 APPROVED: Redacted for Privacy Professor of Computer Science in charge ofmajor Redacted for Privacy Head of Department of Computer Science Redacted for Privacy Dean of Gradu to School Or Date thesis presented February 6, 1992 Typed by Sungwoon Choi for Sungwoon Choi To my wife Yejung ACKNOWLEDGEMENTS I would like to express my sincere gratitude tomy major professor, Dr.
    [Show full text]
  • An Efficient Implementation of Guard-Based Synchronization for an Object-Oriented Programming Language an Efficient Implementation of Guard-Based
    AN EFFICIENT IMPLEMENTATION OF GUARD-BASED SYNCHRONIZATION FOR AN OBJECT-ORIENTED PROGRAMMING LANGUAGE AN EFFICIENT IMPLEMENTATION OF GUARD-BASED SYNCHRONIZATION FOR AN OBJECT-ORIENTED PROGRAMMING LANGUAGE By SHUCAI YAO, M.Sc., B.Sc. A Thesis Submitted to the Department of Computing and Software and the School of Graduate Studies of McMaster University in Partial Fulfilment of the Requirements for the Degree of Doctor of Philosophy McMaster University c Copyright by Shucai Yao, July 2020 Doctor of Philosophy (2020) McMaster University (Computing and Software) Hamilton, Ontario, Canada TITLE: An Efficient Implementation of Guard-Based Synchro- nization for an Object-Oriented Programming Language AUTHOR: Shucai Yao M.Sc., (Computer Science) University of Science and Technology Beijing B.Sc., (Computer Science) University of Science and Technology Beijing SUPERVISOR: Dr. Emil Sekerinski, Dr. William M. Farmer NUMBER OF PAGES: xvii,167 ii To my beloved family Abstract Object-oriented programming has had a significant impact on software development because it provides programmers with a clear structure of a large system. It encap- sulates data and operations into objects, groups objects into classes and dynamically binds operations to program code. With the emergence of multi-core processors, application developers have to explore concurrent programming to take full advan- tage of multi-core technology. However, when it comes to concurrent programming, object-oriented programming remains elusive as a useful programming tool. Most object-oriented programming languages do have some extensions for con- currency, but concurrency is implemented independently of objects: for example, concurrency in Java is managed separately with the Thread object. We employ a programming model called Lime that combines action systems tightly with object- oriented programming and implements concurrency by extending classes with actions and guarded methods.
    [Show full text]
  • Designing Software Architecture to Support Continuous Delivery and Devops: a Systematic Literature Review
    Designing Software Architecture to Support Continuous Delivery and DevOps: A Systematic Literature Review Robin Bolscher and Maya Daneva University of Twente, Drienerlolaan 5, Enschede, The Netherlands [email protected], [email protected] Keywords: Software Architecture, Continuous Delivery, Continuous Integration, DevOps, Deployability, Systematic Literature Review, Micro-services. Abstract: This paper presents a systematic literature review of software architecture approaches that support the implementation of Continuous Delivery (CD) and DevOps. Its goal is to provide an understanding of the state- of-the-art on the topic, which is informative for both researchers and practitioners. We found 17 characteristics of a software architecture that are beneficial for CD and DevOps adoption and identified ten potential software architecture obstacles in adopting CD and DevOps in the case of an existing software system. Moreover, our review indicated that micro-services are a dominant architectural style in this context. Our literature review has some implications: for researchers, it provides a map of the recent research efforts on software architecture in the CD and DevOps domain. For practitioners, it describes a set of software architecture principles that possibly can guide the process of creating or adapting software systems to fit in the CD and DevOps context. 1 INTRODUCTION designing new software architectures tailored for CD and DevOps practices. The practice of releasing software early and often has For clarity, before elaborating on the subject of been increasingly more adopted by software this SLR, we present the definitions of the concepts organizations (Fox et al., 2014) in order to stay that we will address: Software architecture of a competitive in the software market.
    [Show full text]
  • Concurrency Patterns for Easier Robotic Coordination
    Concurrency Patterns for Easier Robotic Coordination Andrey Rusakov∗ Jiwon Shin∗ Bertrand Meyer∗† ∗Chair of Software Engineering, Department of Computer Science, ETH Zurich,¨ Switzerland †Software Engineering Lab, Innopolis University, Kazan, Russia fandrey.rusakov, jiwon.shin, [email protected] Abstract— Software design patterns are reusable solutions to Guarded suspension – are chosen for their concurrent nature, commonly occurring problems in software development. Grow- applicability to robotic coordination, and evidence of use ing complexity of robotics software increases the importance of in existing robotics frameworks. The paper aims to help applying proper software engineering principles and methods such as design patterns to robotics. Concurrency design patterns programmers who are not yet experts in concurrency to are particularly interesting to robotics because robots often have identify and then to apply one of the common concurrency- many components that can operate in parallel. However, there based solutions for their applications on robotic coordination. has not yet been any established set of reusable concurrency The rest of the paper is organized as follows: After design patterns for robotics. For this purpose, we choose six presenting related work in Section II, it proceeds with a known concurrency patterns – Future, Periodic timer, Invoke later, Active object, Cooperative cancellation, and Guarded sus- general description of concurrency approach for robotics pension. We demonstrate how these patterns could be used for in Section III. Then the paper presents and describes in solving common robotic coordination tasks. We also discuss detail a number of concurrency patterns related to robotic advantages and disadvantages of the patterns and how existing coordination in Section IV.
    [Show full text]
  • The Evolution of Control Architectures Towards Next Generation
    Department of Electronic and Electrical Engineering University College London University of London T h e Ev o l u t io n o f C o n t r o l A rchitectures T o w a r d s N ext G e n e r a t io n N e t w o r k s By Christos Solomonides BEng(Hons), MRes(Distinction) 7 September 2001 A thesis submitted to the University o f London for the Ph.D. in Electronic and Electrical Engineering ProQuest Number: U643054 All rights reserved INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion. uest. ProQuest U643054 Published by ProQuest LLC(2016). Copyright of the Dissertation is held by the Author. All rights reserved. This work is protected against unauthorized copying under Title 17, United States Code. Microform Edition © ProQuest LLC. ProQuest LLC 789 East Eisenhower Parkway P.O. Box 1346 Ann Arbor, Ml 48106-1346 A b s t r a c t This thesis describes the evolution of control architectures and network intelligence towards next generation telecommunications networks. Network intelligence is a term given to the group of architectures that provide enhanced control services. Network intelligence is provided through the control plane, which is responsible for the establishment, operation and termination of calls and connections. The work focuses on examining the way in which network intelligence has been provided in the traditional telecommunications environment and in a converging environment.
    [Show full text]
  • Software Engineering (SE) 1
    Software Engineering (SE) 1 SE 352 | OBJECT-ORIENTED ENTERPRISE APPLICATION DEVELOPMENT SOFTWARE ENGINEERING | 4 quarter hours (Undergraduate) (SE) This course focuses on applying object-oriented techniques in the design and development of software systems for enterprise applications. Topics SE 325 | INTRODUCTION TO SOFTWARE ENGINEERING | 4 quarter hours include component architecture, such as Java Beans and Enterprise (Undergraduate) Java Beans, GUI components, such as Swing, database connectivity and This course introduces students to the activities performed at each object repositories, server application integration using technologies stage of the development process so that they can understand the full such as servlets, Java Server Pages, JDBC and RMI, security and lifecycle context of specific tasks such as coding and testing. Topics will internationalization. PREREQUISITE(S): CSC 301. include software development processes, domain modeling, requirements CSC 301 is a prerequisite for this class. elicitation and specification, architectural design and analysis, product SE 356 | SOFTWARE DEVELOPMENT FOR MOBILE AND WIRELESS and process level metrics, configuration management, quality assurance SYSTEMS | 4 quarter hours activities including user acceptance testing and unit testing, project (Undergraduate) management skills such as risk analysis, effort estimation, project This course will focus on the unique aspects of developing software release planning, and software engineering ethics. applications for mobile and wireless systems, such as personal digital CSC 301 or CSC 393 is a prerequisite for this class. assistant (PDA) devices and mobile phones. Topics will include user SE 330 | OBJECT ORIENTED MODELING | 4 quarter hours interface design for small screens with restricted input modalities, data (Undergraduate) synchronization for mobile databases as well as wireless programming Object-oriented modeling techniques for analysis and design.
    [Show full text]
  • Active Object
    Active Object an Object Behavioral Pattern for Concurrent Programming R. Greg Lavender Douglas C. Schmidt [email protected] [email protected] ISODE Consortium Inc. Department of Computer Science Austin, TX Washington University, St. Louis An earlier version of this paper appeared in a chapter in the book ªPattern Languages of Program Design 2º ISBN 0-201-89527-7, edited by John Vlissides, Jim Coplien, and Norm Kerth published by Addison-Wesley, 1996. : Output : Input Handler Handler : Routing Table : Message Abstract Queue This paper describes the Active Object pattern, which decou- 3: enqueue(msg) ples method execution from method invocation in order to : Output 2: find_route(msg) simplify synchronized access to a shared resource by meth- Handler ods invoked in different threads of control. The Active Object : Message : Input pattern allows one or more independent threads of execution Queue Handler 1: recv(msg) to interleave their access to data modeled as a single ob- ject. A broad class of producer/consumer and reader/writer OUTGOING OUTGOING MESSAGES GATEWAY problems are well-suited to this model of concurrency. This MESSAGES pattern is commonly used in distributed systems requiring INCOMING INCOMING multi-threaded servers. In addition,client applications (such MESSAGES MESSAGES as windowing systems and network browsers), are increas- DST DST ingly employing active objects to simplify concurrent, asyn- SRC SRC chronous network operations. 1 Intent Figure 1: Connection-Oriented Gateway The Active Object pattern decouples method execution from method invocation in order to simplify synchronized access to a shared resource by methods invoked in different threads [2]. Sources and destinationscommunicate with the Gateway of control.
    [Show full text]
  • The Origins of Pattern Theory: the Future of the Theory, and the Generation of a Living World
    www.computer.org/software The Origins of Pattern Theory: The Future of the Theory, and the Generation of a Living World Christopher Alexander Vol. 16, No. 5 September/October 1999 This material is presented to ensure timely dissemination of scholarly and technical work. Copyright and all rights therein are retained by authors or by other copyright holders. All persons copying this information are expected to adhere to the terms and constraints invoked by each author's copyright. In most cases, these works may not be reposted without the explicit permission of the copyright holder. © 2006 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE. For more information, please see www.ieee.org/portal/pages/about/documentation/copyright/polilink.html. 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.
    [Show full text]