DOCSLIB.ORG

Application of the Mediator Design Pattern to Monte Carlo Simulation in Genetic Epidemiology

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Application of the Mediator Design Pattern to Monte Carlo Simulation in Genetic Epidemiology APPLICATION OF THE MEDIATOR DESIGN PATTERN TO MONTE CARLO SIMULATION IN GENETIC EPIDEMIOLOGY by KEVIN C. CARTIER Submitted in partial fulfillment of the requirements For the degree of Master of Science Thesis Adviser: Courtney Gray-McGuire, Ph.D. Department of Epidemiology and Biostatistics CASE WESTERN RESERVE UNIVERSITY August, 2008 Contents 1 Introduction 1 1.1 Genetic Epidemiology . 1 1.1.1 Scope of Inquiry in Genetic Epidemiology . 2 1.1.2 Data Structures and Formats . 4 1.1.3 Models . 8 1.1.4 Observational Data . 11 1.2 Software Design . 12 1.2.1 Object-Oriented Design . 14 1.2.2 Software Design Patterns . 16 1.2.2.1 Creational Patterns . 17 1.2.2.2 Structural Patterns . 18 1.2.2.3 Behavioral Patterns . 18 1.2.3 The Mediator Pattern . 20 1.3 Simulation . 23 1.3.1 Computers and Randomness . 24 1.3.2 Monte Carlo Simulation . 25 1.3.3 Experiment by Simulation . 26 i 1.3.4 Simulation in Statistical Genetics . 27 1.4 Two Prevailing Methods . 29 1.4.1 Agent-Based Design . 30 1.4.2 Structure-Based Design . 31 1.5 Summary . 31 2 Background and Literature Review 34 2.1 Genotype Simulation . 34 2.1.1 Gene Dropping . 34 2.1.2 Haplotype Simulation . 39 2.2 Phenotype Simulation . 40 2.2.1 Simulating a Continuous Trait from Genotype . 40 2.2.2 Simulating a Binary Trait from Genotype . 43 2.3 Simulating Population Clustering Structures . 43 2.4 Simulating Recombination . 44 2.5 Estimating Statistical Power . 45 2.5.1 Statistical Testing and Power . 45 2.5.2 Estimating Power to Detect Linkage . 45 2.6 Program Survey . 50 ii 2.6.1 QU-GENE . 50 2.6.2 METASIM . 51 2.6.3 GAW 10: Simulated Family Data . 52 2.6.4 GAW 11: Simulated Multifactoral Data . 52 2.6.5 GAW 12: Simulated Multifactoral Data . 53 2.6.6 GAW 13: Simulated Longitudinal Data . 54 2.6.7 SAIL . 54 2.6.8 SNAPPERS . 55 2.6.9 SIMIBD . 56 2.6.10 GENOOM . 57 2.6.11 Genetic Simulation Library (GSL) . 57 2.6.12 POPSIM . 59 2.7 Summary . 60 3 Thesis 62 3.1 Thesis Statement . 62 3.2 Specific Aims . 62 3.2.1 Aim 1: Design and Implementation of the Core Simulation Program . 63 3.2.2 Aim 2: Design and Implementation of the User Interface . 64 iii 3.2.3 Aim 3: Design and Implementation of the Output Interface . 64 3.2.4 Aim 4: Validation against Existing Data Sets . 65 4 Software Design 66 4.1 Program Architecture . 66 4.1.1 The Essential Message Types . 68 4.1.2 The Message Cycle . 70 4.1.3 The Primary Control Loop . 71 4.1.4 Default Object Behavior . 73 4.2 The User Interface . 74 4.3 Simulation Parameters . 74 4.3.1 Genome Parameters . 76 4.3.2 General Operating Parameters . 77 4.3.3 Population Parameters . 79 4.3.4 Individual Parameters . 80 4.3.5 Trait/Phenotype Parameters . 81 4.3.6 Genomic/Genotypic Parameters . 82 4.4 Integration with S.A.G.E. Libraries . 83 iv 5 Methods 84 5.1 Simulation Methods . 84 5.1.1 General Parameters . 84 5.1.2 Genome Simulation . 84 5.1.3 Population Simulation . 85 5.1.3.1 The Founding Generation . 85 5.1.3.2 Pairing & Procreation . 86 5.1.4 The Admixture Proportion Vector . 87 5.1.5 Individuals . 89 5.1.5.1 Individual Genotypes . 89 5.1.5.2 Individual Phenotypes . 91 5.1.6 Ascertainment . 92 5.2 Software Validation . 92 5.2.1 The GAW12 Phenotype Model . 93 5.2.2 Models for Linkage Analysis . 95 6 Results & Discussion 98 6.1 gSim Replicates . 98 6.2 Comparative Data Set Distributions . 99 6.3 Validation Results . 104 v 7 Conclusion 111 vi List of Tables 1 gSim Summary Statistics . 100 2 GAW12 Summary Statistics . 100 vii List of Figures 1 The Scope of Genetic Epidemiology . 3 2 Example Data for Genetic Epidemiology . 6 3 Example Pedigree Diagram . 7 4 Example of Relational Database Format for Pedigree Data . 8 5 The Process of Scientific Inquiry . 10 6 The Context of Software Development . 13 7 Object-Oriented Software Design . 15 8 Interface Complexity . 20 9 Gene-Dropping Example . 35 10 Pedigree with Affected Sibling Pair (ASP) . 36 11 Example Pedigree . 47 12 Partitions of Software Design . 63 13 gSim Class Relationships . 67 14 gSim Architecture . 69 15 Primary Control Loop . 72 16 Object Behavior . 75 17 gSim Genome Description File Format . 77 18 S.A.G.E. Genome Description File Format . 78 19 Admixed Populations . 88 20 The Admixture Proportion Vector . 89 21 The GAW12 Phenotype Model (Almasy et al. , 2001) . 94 22 The Phenotype used for gSim Validation . 97 23 Example gSim Pedigree Data . 99 24 Frequency Distribution of Q3 Mean Values across gSim Replicates . 101 viii 25 Frequency Distribution of Q3 Mean Values across GAW12 Replicates102 26 A Typical gSim-Generated Replicate . 103 27 Multi-marker H-E Linkage Analysis of Q3 on Chromosome 2 (gSim replicate) . 105 28 Multi-marker H-E Linkage Analysis of Q3 on Chromosome 17 (GAW12 replicate) . 105 29 Summary of gSim Data Analysis (Replicates 1 - 10) . 107 30 Model_1 Parameter Estimates for gSim Replicates . 107 31 Model_1 log(P-value) for gSim Replicates . 108 32 gSim vs. GAW12 Comparison of Replicates via Mosely et al. 110 ix Application of the Mediator Design Pattern to Monte Carlo Simulation in Genetic Epidemiology Abstract by KEVIN C CARTIER Genetic epidemiology relies on simulated data to support development of theory and methods. Simulated data are designed to reflect, as accurately as possible, the true phenotypic and genotypic distributions of individuals sampled from different types of relationship clusters. Common simulation methods can be classified into two groups: agent-based methods, in which individuals are simulated, one at a time, according to the rules of Mendelian inheritance and other assumptions, and structure-based methods, in which aggregates of individuals exhibiting properties of interest are simulated, with genotypic information inferred conditionally on both phenotype and structure. A previously untried software design is proposed to sup- port both agent-based and structure-based simulation with equal facility. The medi- ator design pattern is applied to simulation design, and is shown to (1) reduce the complexities arising from the potentially huge number of communication channels required between autonomous agents and (2) to provide an efficient mechanism by which higher-level system objects may override default behaviors of lower-level objects. x DEDICATION This work is dedicated to my wife Mary, whose gracious and loving care for our children exemplifies the word dedication. And as far as I can tell, she is also the reason the sun rises and sets every day. I would also like to commemorate my father Charles, who died earlier this year. Foremost among the many life-lessons he taught me were the values of language, organization, persistence and clarity of thought, all of which are (I hope) evident within within these pages. Nothing in the world can take the place of persistence. Talent will not; nothing is more common than unsuccessful men with talent. Genius will not; unrewarded genius is almost a proverb. Education will not; the world is full of educated derelicts. Persistence and determination alone are omnipotent. Calvin Coolidge xi ACKNOWLEDGEMENTS I would like to thank the members of my thesis advisory committee for their time and effort in reviewing drafts of the manuscript and for the many constructive sug- gestions they provided. The list of students who have at one time or another been advised or taught by Dr. Robert Elston is very long by now, and I feel privileged to be included in that list. I am especially grateful to Dr. Courtney Gray-McGuire, whose consistently prag- matic advice and guidance were always on target, and on more than one occasion prevented me from needlessly widening the scope of the project. There is a long- standing in-joke about computer programmers who “shoot themselves in the foot” due to overly elaborate design choices, and if I have managed to avoid doing so on this project then much of the credit must go to Dr. Gray-McGuire for keeping me properly focused throughout the course of development. xii 1 Introduction As a field of scientific research, genetic epidemiology relies heavily on simulated data, for both generation and testing of hypotheses. Historically, simulated data have been produced by computer programs in a wide variety of software design and implementation schemes. It is therefore reasonable to ask whether or not existing simulation designs and implementations are sufficient for the current and future needs of researchers in the field. Further, in areas of existing design that are found to be lacking, we would like to identify a previously untried design with the potential to correct those inadequacies. The question of optimal simulation design for genetic epidemiology is herein addressed by first examining the role of simulation within the overall process of scientific inquiry. Before evaluating any actual or idealized simulation designs, we shall first review the context in which simulated data are generated and analyzed..
Load more

Recommended publications
  • Design Pattern Interview Questions
    DDEESSIIGGNN PPAATTTTEERRNN -- IINNTTEERRVVIIEEWW QQUUEESSTTIIOONNSS http://www.tutorialspoint.com/design_pattern/design_pattern_interview_questions.htm Copyright © tutorialspoint.com Dear readers, these Design Pattern Interview Questions have been designed specially to get you acquainted with the nature of questions you may encounter during your interview for the subject of Design Pattern. As per my experience good interviewers hardly plan to ask any particular question during your interview, normally questions start with some basic concept of the subject and later they continue based on further discussion and what you answer: What are Design Patterns? Design patterns represent the best practices used by experienced object-oriented software developers. Design patterns are solutions to general problems that software developers faced during software development. These solutions were obtained by trial and error by numerous software developers over quite a substantial period of time. What is Gang of Four GOF? In 1994, four authors Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides published a book titled Design Patterns - Elements of Reusable Object-Oriented Software which initiated the concept of Design Pattern in Software development. These authors are collectively known as Gang of Four GOF. Name types of Design Patterns? Design patterns can be classified in three categories: Creational, Structural and Behavioral patterns. Creational Patterns - These design patterns provide a way to create objects while hiding the creation logic, rather than instantiating objects directly using new opreator. This gives program more flexibility in deciding which objects need to be created for a given use case. Structural Patterns - These design patterns concern class and object composition. Concept of inheritance is used to compose interfaces and define ways to compose objects to obtain new functionalities.
    [Show full text]
  • Design Patterns in PHP and Laravel — Kelt Dockins Design Patterns in PHP and Laravel
    Design Patterns in PHP and Laravel — Kelt Dockins Design Patterns in PHP and Laravel Kelt Dockins [email protected] Design Patterns in PHP and Laravel Kelt Dockins Dolph, Arkansas USA ISBN-13 (pbk): 978-1-4842-2450-2 ISBN-13 (electronic): 978-1-4842-2451-9 DOI 10.1007/978-1-4842-2451-9 Library of Congress Control Number: 2016961807 Copyright © 2017 by Kelt Dockins This work is subject to copyright. All rights are reserved by the Publisher, whether the whole or part of the material is concerned, specifically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on microfilms or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed. Trademarked names, logos, and images may appear in this book. Rather than use a trademark symbol with every occurrence of a trademarked name, logo, or image we use the names, logos, and images only in an editorial fashion and to the benefit of the trademark owner, with no intention of infringement of the trademark. The use in this publication of trade names, trademarks, service marks, and similar terms, even if they are not identified as such, is not to be taken as an expression of opinion as to whether or not they are subject to proprietary rights. While the advice and information in this book are believed to be true and accurate at the date of publication, neither the authors nor the editors nor the publisher can accept any legal responsibility for any errors or omissions that may be made.
    [Show full text]
  • Enterprise Development with Flex
    Enterprise Development with Flex Enterprise Development with Flex Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky Beijing • Cambridge • Farnham • Köln • Sebastopol • Taipei • Tokyo Enterprise Development with Flex by Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky Copyright © 2010 Yakov Fain, Victor Rasputnis, and Anatole Tartakovsky.. All rights reserved. Printed in the United States of America. Published by O’Reilly Media, Inc., 1005 Gravenstein Highway North, Sebastopol, CA 95472. O’Reilly books may be purchased for educational, business, or sales promotional use. Online editions are also available for most titles (http://my.safaribooksonline.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or [email protected]. Editor: Mary E. Treseler Indexer: Ellen Troutman Development Editor: Linda Laflamme Cover Designer: Karen Montgomery Production Editor: Adam Zaremba Interior Designer: David Futato Copyeditor: Nancy Kotary Illustrator: Robert Romano Proofreader: Sada Preisch Printing History: March 2010: First Edition. Nutshell Handbook, the Nutshell Handbook logo, and the O’Reilly logo are registered trademarks of O’Reilly Media, Inc. Enterprise Development with Flex, the image of red-crested wood-quails, and related trade dress are trademarks of O’Reilly Media, Inc. Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and O’Reilly Media, Inc. was aware of a trademark claim, the designations have been printed in caps or initial caps. While every precaution has been taken in the preparation of this book, the publisher and authors assume no responsibility for errors or omissions, or for damages resulting from the use of the information con- tained herein.
    [Show full text]
  • Learning Javascript Design Patterns
    Learning JavaScript Design Patterns Addy Osmani Beijing • Cambridge • Farnham • Köln • Sebastopol • Tokyo Learning JavaScript Design Patterns by Addy Osmani Copyright © 2012 Addy Osmani. All rights reserved. Revision History for the : 2012-05-01 Early release revision 1 See http://oreilly.com/catalog/errata.csp?isbn=9781449331818 for release details. ISBN: 978-1-449-33181-8 1335906805 Table of Contents Preface ..................................................................... ix 1. Introduction ........................................................... 1 2. What is a Pattern? ...................................................... 3 We already use patterns everyday 4 3. 'Pattern'-ity Testing, Proto-Patterns & The Rule Of Three ...................... 7 4. The Structure Of A Design Pattern ......................................... 9 5. Writing Design Patterns ................................................. 11 6. Anti-Patterns ......................................................... 13 7. Categories Of Design Pattern ............................................ 15 Creational Design Patterns 15 Structural Design Patterns 16 Behavioral Design Patterns 16 8. Design Pattern Categorization ........................................... 17 A brief note on classes 17 9. JavaScript Design Patterns .............................................. 21 The Creational Pattern 22 The Constructor Pattern 23 Basic Constructors 23 Constructors With Prototypes 24 The Singleton Pattern 24 The Module Pattern 27 iii Modules 27 Object Literals 27 The Module Pattern
    [Show full text]
  • Design Pattern Implementation in Java and Aspectj
    Design Pattern Implementation in Java and AspectJ Jan Hannemann Gregor Kiczales University of British Columbia University of British Columbia 201-2366 Main Mall 201-2366 Main Mall Vancouver B.C. V6T 1Z4 Vancouver B.C. V6T 1Z4 jan [at] cs.ubc.ca gregor [at] cs.ubc.ca ABSTRACT successor in the chain. The event handling mechanism crosscuts the Handlers. AspectJ implementations of the GoF design patterns show modularity improvements in 17 of 23 cases. These improvements When the GoF patterns were first identified, the sample are manifested in terms of better code locality, reusability, implementations were geared to the current state of the art in composability, and (un)pluggability. object-oriented languages. Other work [19, 22] has shown that implementation language affects pattern implementation, so it seems The degree of improvement in implementation modularity varies, natural to explore the effect of aspect-oriented programming with the greatest improvement coming when the pattern solution techniques [11] on the implementation of the GoF patterns. structure involves crosscutting of some form, including one object As an initial experiment we chose to develop and compare Java playing multiple roles, many objects playing one role, or an object [27] and AspectJ [25] implementations of the 23 GoF patterns. playing roles in multiple pattern instances. AspectJ is a seamless aspect-oriented extension to Java, which means that programming in AspectJ is effectively programming in Categories and Subject Descriptors Java plus aspects. D.2.11 [Software Engineering]: Software Architectures – By focusing on the GoF patterns, we are keeping the purpose, patterns, information hiding, and languages; D.3.3 intent, and applicability of 23 well-known patterns, and only allowing [Programming Languages]: Language Constructs and Features – the solution structure and solution implementation to change.
    [Show full text]
  • Java Design Patterns I
    Java Design Patterns i Java Design Patterns Java Design Patterns ii Contents 1 Introduction to Design Patterns 1 1.1 Introduction......................................................1 1.2 What are Design Patterns...............................................1 1.3 Why use them.....................................................2 1.4 How to select and use one...............................................2 1.5 Categorization of patterns...............................................3 1.5.1 Creational patterns..............................................3 1.5.2 Structural patterns..............................................3 1.5.3 Behavior patterns...............................................3 2 Adapter Design Pattern 5 2.1 Adapter Pattern....................................................5 2.2 An Adapter to rescue.................................................6 2.3 Solution to the problem................................................7 2.4 Class Adapter..................................................... 11 2.5 When to use Adapter Pattern............................................. 12 2.6 Download the Source Code.............................................. 12 3 Facade Design Pattern 13 3.1 Introduction...................................................... 13 3.2 What is the Facade Pattern.............................................. 13 3.3 Solution to the problem................................................ 14 3.4 Use of the Facade Pattern............................................... 16 3.5 Download the Source Code.............................................
    [Show full text]
  • Object-Oriented Design Patterns
    Object-Oriented Design Patterns David Janzen EECS 816 Object-Oriented Software Development University of Kansas Outline • Introduction – Design Patterns Overview – Strategy as an Early Example – Motivation for Creating and Using Design Patterns – History of Design Patterns • Gang of Four (GoF) Patterns – Creational Patterns – Structural Patterns – Behavioral Patterns Copyright © 2006 by David S. 2 Janzen. All rights reserved. What are Design Patterns? • In its simplest form, a pattern is a solution to a recurring problem in a given context • Patterns are not created, but discovered or identified • Some patterns will be familiar? – If you’ve been designing and programming for long, you’ve probably seen some of the patterns we will discuss – If you use Java Foundation Classes (Swing), Copyright © 2006 by David S. 3 you have certaJiannzleyn. Aulls rieghdts rsesoervmed.e design patterns Design Patterns Definition1 • Each pattern is a three-part rule, which expresses a relation between – a certain context, – a certain system of forces which occurs repeatedly in that context, and – a certain software configuration which allows these forces to resolve themselves 1. Dick Gabriel, http://hillside.net/patterns/definition.html Copyright © 2006 by David S. 4 Janzen. All rights reserved. A Good Pattern1 • Solves a problem: – Patterns capture solutions, not just abstract principles or strategies. • Is a proven concept: – Patterns capture solutions with a track record, not theories or speculation 1. James O. Coplien, http://hillside.net/patterns/definition.html Copyright © 2006 by David S. 5 Janzen. All rights reserved. A Good Pattern • The solution isn't obvious: – Many problem-solving techniques (such as software design paradigms or methods) try to derive solutions from first principles.
    [Show full text]
  • Design Patterns Mock Test
    DDEESSIIGGNN PPAATTTTEERRNNSS MMOOCCKK TTEESSTT http://www.tutorialspoint.com Copyright © tutorialspoint.com This section presents you various set of Mock Tests related to Design Patterns Framework. You can download these sample mock tests at your local machine and solve offline at your convenience. Every mock test is supplied with a mock test key to let you verify the final score and grade yourself. DDEESSIIGGNN PPAATTTTEERRNNSS MMOOCCKK TTEESSTT IIII Q 1 - Which of the following describes the Composite pattern correctly? A - This pattern builds a complex object using simple objects and using a step by step approach. B - This pattern is used where we need to treat a group of objects in similar way as a single object. C - This pattern hides the complexities of the system and provides an interface to the client using which the client can access the system. D - This pattern is primarily used to reduce the number of objects created and to decrease memory footprint and increase performance. Q 2 - Which of the following describes the Decorator pattern correctly? A - This pattern allows a user to add new functionality to an existing object without altering its structure. B - This pattern is used where we need to treat a group of objects in similar way as a single object. C - This pattern hides the complexities of the system and provides an interface to the client using which the client can access the system. D - This pattern is primarily used to reduce the number of objects created and to decrease memory footprint and increase performance. Q 3 - Which of the following describes the Facade pattern correctly? A - This pattern allows a user to add new functionality to an existing object without altering its structure.
    [Show full text]
  • Developing GUI Applications. Architectural Patterns Revisited
    Developing GUI Applications: Architectural Patterns Revisited A Survey on MVC, HMVC, and PAC Patterns Alexandros Karagkasidis [email protected] Abstract. Developing large and complex GUI applications is a rather difficult task. Developers have to address various common soFtware engineering problems and GUI-speciFic issues. To help the developers, a number of patterns have been proposed by the software community. At the architecture and higher design level, the Model-View-Controller (with its variants) and the Presentation-Abstraction- Control are two well-known patterns, which specify the structure oF a GUI application. However, when applying these patterns in practice, problems arise, which are mostly addressed to an insuFFicient extent in the existing literature (iF at all). So, the developers have to find their own solutions. In this paper, we revisit the Model-View-Controller, Hierarchical Model-View- Controller, and Presentation-Abstraction-Control patterns. We first set up a general context in which these patterns are applied. We then identiFy Four typical problems that usually arise when developing GUI applications and discuss how they can be addressed by each of the patterns, based on our own experience and investigation oF the available literature. We hope that this paper will help GUI developers to address the identified issues, when applying these patterns. 1 Introduction Developing a large and complex graphical user interface (GUI) application for displaying, working with, and managing complex business data and processes is a rather difficult task. A common problem is tackling system complexity. For instance, one could really get lost in large number of visual components comprising the GUI, not to mention the need to handle user input or track all the relationships between the GUI and the business logic components.
    [Show full text]
  • Design Patterns for Developing High Efficiency Mobile Application
    chnology Te & n S o o ti ft a w a m r r e Shahbudin and Chua, J Inform Tech Softw Eng 2013, 3:3 o f E Journal of n n I g f i o n DOI; 10.4172/2165-7866.1000122 l e a e n r r i n u g o J ISSN: 2165-7866 Information Technology & Software Engineering Research Article Open Access Design Patterns for Developing High Efficiency Mobile Application Fadilah Ezlina Shahbudin and Fang-Fang Chua* Faculty of Computing and Informatics, Multimedia University, Cyberjaya, Malaysia Abstract With the advent of technology, mobile devices are becoming powerful and they are widely used as convenient computing devices. In order to develop high quality application in a short period while overcoming the limitations and challenges in mobile development, strong knowledge and understanding of the design purpose are the key factors in developing well- designed applications. Good design ensures that crashes or harmful actions can be prevented as well as increasing users’ satisfaction. By implementing design patterns, developers can cater wide variety of users whereby they do not have to redevelop similar application for users who are using different types of devices. Application can be developed in a short period as developer can reuse design patterns to develop new application in similar domain. Our proposed work aims to implement design patterns to overcome limitations of current techniques and increase efficiency, usability and reusability in mobile application development. Keywords: Design patterns; Mobile application; Efficiency; Usability; many aspects and factors that need to be considered to achieve the Development specified quality attributes.
    [Show full text]
  • Gang-Of-Four Design Patterns: a Case Study of the Unified Om Del and the Eos Programming Language Hridesh Rajan Iowa State University, [email protected]
    Computer Science Technical Reports Computer Science Summer 6-30-2015 Gang-of-Four Design Patterns: A Case Study of the Unified oM del and the Eos Programming Language Hridesh Rajan Iowa State University, [email protected] Follow this and additional works at: http://lib.dr.iastate.edu/cs_techreports Part of the Programming Languages and Compilers Commons, and the Software Engineering Commons Recommended Citation Rajan, Hridesh, "Gang-of-Four Design Patterns: A Case Study of the Unified Model and the Eos Programming Language" (2015). Computer Science Technical Reports. 373. http://lib.dr.iastate.edu/cs_techreports/373 This Article is brought to you for free and open access by the Computer Science at Iowa State University Digital Repository. It has been accepted for inclusion in Computer Science Technical Reports by an authorized administrator of Iowa State University Digital Repository. For more information, please contact [email protected]. Gang-of-Four Design Patterns: A Case Study of the Unified oM del and the Eos Programming Language Abstract In earlier work, we showed that the AspectJ notions of aspect and class can be unified in a new module construct that we called the classpect, and that this new model is simpler and able to accommodate a broader set of requirements for modular solutions to complex integration problems. We embodied our unified model in the Eos language design. The ainm contribution of this article is a case study, which considers the implementation of the Gang-of-Four (GOF) design patterns in Eos to analyze the effect of new programming language constructs on these implementations. We also compare these implementations with the AspectJ's implementation.
    [Show full text]
  • Mediator Pattern
    Mediator Pattern a.k.a. Broker a.k.a. Vermittler 1 © 2009, Sebastian Gäng, Moritz Moll, Design Pattern, HTWG Konstanz Beschreibung Hochschule Konstanz Klifikilassifikation: Obje kt bas iertes Verhlhaltensmuster ZkZweck: Wenn eine Menge von Obje kten untitereinan der kommunizieren wird eine Indirektion eingebaut d.h. die Objekte reden nicht mehr direkt miteinander sondern indirekt über den „Mediator“ / „Vermittler“. "Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently." (Gamma et al., 1995) 2 © 2009, Sebastian Gäng, Moritz Moll, Design Pattern, HTWG Konstanz Motivation Hochschule Konstanz Vorher: Kollege Kollege Kollege Kollege Kollege 3 © 2009, Sebastian Gäng, Moritz Moll, Design Pattern, HTWG Konstanz Motivation Hochschule Konstanz Nachher: Kollege Kollege Vermittler Kollege Kollege Kollege 4 © 2009, Sebastian Gäng, Moritz Moll, Design Pattern, HTWG Konstanz Motivation / Beispiel Hochschule Konstanz Chat: Viele Anwender (Collegues) unterhalten sich: ‐ Ungünstig alle untereinander zu verbinden ‐ MditMediator itist der Cha troom Fluglotsen: ‐ Flugzeuge (Collegues) können sich nicht alle untereinander verständigen Æ Kontrollcenter 5 © 2009, Sebastian Gäng, Moritz Moll, Design Pattern, HTWG Konstanz Struktur Hochschule Konstanz 6 © 2009, Sebastian Gäng, Moritz Moll, Design Pattern, HTWG Konstanz Struktur Hochschule Konstanz Beispiel Flugverkehr: 7 © 2009, Sebastian Gäng, Moritz Moll, Design Pattern, HTWG Konstanz Struktur Hochschule Konstanz Beispiel Flugverkehr: 8 © 2009, Sebastian Gäng, Moritz Moll, Design Pattern, HTWG Konstanz Teilnehmer Hochschule Konstanz Mediator ‐ defines the interface for communication between Colleague objects Concrete Mediator ‐ implements the Mediator interface and coordinates communication between Colleague objects. It is aware of all the Colleagues and their purpose with regards to inter communication.
    [Show full text]